Hi,
Do we have any comments on the sound server topic from a broader perspective than only GNOME?
A competing proposal I've heard is to just use ALSA directly.
I believe this is orthogonal to something like Helix/GStreamer which would both output to the sound server, but the maintainers of those media frameworks probably care about the discussion.
A nice Fedora goal at some point would be to get all packages using the same sound setup.
Havoc
On Thu, 2004-10-28 at 14:11 -0400, Havoc Pennington wrote:
Hi,
Do we have any comments on the sound server topic from a broader perspective than only GNOME?
A competing proposal I've heard is to just use ALSA directly.
I believe this is orthogonal to something like Helix/GStreamer which would both output to the sound server, but the maintainers of those media frameworks probably care about the discussion.
A nice Fedora goal at some point would be to get all packages using the same sound setup.
Havoc
I was going to reply to this thread. It seems Jeff really likes Polyaudio so I am going to go ahead and make some packages. It looks like I might have to split out a libesound package for now. The biggest problem from what Jeff said would be converting all our packages to use Polyaudio's API.
email message attachment, "Forwarded message - Proposal: replacing esound with polypaudio in 2.10" On Thu, 2004-10-28 at 14:11 -0400, Havoc Pennington wrote:
Hi!
I would like to propose Polypaudio as a replacement for ESOUND in Gnome 2.10. Polypaudio is a sound server I have been developing for the last months. It aims to be a drop-in replacement for esound fixing all those problems esound has. For more information on polypaudio, see:
http://0pointer.de/lennart/projects/polypaudio/
The two most important requirements for an ESOUND replacement are met with polypaudio: (at least I think that these are the most important issues)
Polypaudio provides an ESOUND compatibility module. When this is enabled polypaudio emulates an esound server, including autospawning and thinks like that. The protocol emulation polypaudio implements is not complete: some of the more esoteric commands are implemented as NOOPs. However, all commands currently used by Gnome 2.8 are available. Keep in mind that polypaudio emulates the protocol, not the library API: i.e. there's no need to patch, recompile or relink any ESOUND based applications for usage with polypaudio.
There's now a polypaudio sink for gstreamer. It's curentely not as featureful as the oss sink, but it is good enough for rhythmbox.
What other requirements have to be met for inclusion of polypaudio in Gnome? I am strongly interested in getting polypaudio in shape for Gnome 2.10 in time: so please, don't hesitate to criticize polypaudio and especially its client API:
http://0pointer.de/lennart/projects/polypaudio/doxygen/
Portability: I develop Polypaudio mostly on Linux. There's some compatibility with OSX, but it is not merged yet. No, it hasn't been ported to Solaris or xBSD yet. However the package makes use of autoconf, so I expect the port is easy to do. Polypaudio has been packaged for Ubuntu by Jeff Waugh, a package for Debian is on its way, as it seems.
Lennart
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
On Thu, Oct 28, 2004 at 02:23:56PM -0400, John (J5) Palmieri wrote:
Polyaudio so I am going to go ahead and make some packages. It looks like I might have to split out a libesound package for now. The biggest problem from what Jeff said would be converting all our packages to use Polyaudio's API.
The biggest problem would be the security audit and the debugging, especially the audit. That is 500Kb of uncommented, impenetrable spaghetti.
On Thu, 2004-10-28 at 15:25 -0400, Alan Cox wrote:
On Thu, Oct 28, 2004 at 02:23:56PM -0400, John (J5) Palmieri wrote:
Polyaudio so I am going to go ahead and make some packages. It looks like I might have to split out a libesound package for now. The biggest problem from what Jeff said would be converting all our packages to use Polyaudio's API.
The biggest problem would be the security audit and the debugging, especially the audit. That is 500Kb of uncommented, impenetrable spaghetti.
I hadn't gotten to the point of looking at the code yet. I was going to make some test packages, see how it worked as an esd replacement and then go ahead and start looking at it. If it is as you say, impenetrable spaghetti, then I don't want to gain yet another unmaintainable package. Is it your position that the things that are wrong with Polyaudio would be harder to fix than just fixing esd? Or perhaps there are better alternatives around? If we can find a solution that is easy to integrate, maintain and audit I am all for that.
John (J5) Palmieri (johnp@redhat.com) said:
I hadn't gotten to the point of looking at the code yet. I was going to make some test packages, see how it worked as an esd replacement and then go ahead and start looking at it. If it is as you say, impenetrable spaghetti, then I don't want to gain yet another unmaintainable package. Is it your position that the things that are wrong with Polyaudio would be harder to fix than just fixing esd? Or perhaps there are better alternatives around? If we can find a solution that is easy to integrate, maintain and audit I am all for that.
Well... direct alsa usage can handle the ESD stuff, as long as you don't care about network audio (and someone may want to write a shim esd-like layer for playback.)
How important is network audio, anyway?
Bill
On Thu, Oct 28, 2004 at 03:43:39PM -0400, Bill Nottingham wrote:
Well... direct alsa usage can handle the ESD stuff, as long as you don't care about network audio (and someone may want to write a shim esd-like layer for playback.)
How important is network audio, anyway?
For any kind of thin client deployment - very. Also for stuff like movie watching between rooms.
How important is network audio, anyway?
Ask the LTSP project and anybody that relies on it.
On Thu, Oct 28, 2004 at 03:37:48PM -0400, John (J5) Palmieri wrote:
I hadn't gotten to the point of looking at the code yet. I was going to make some test packages, see how it worked as an esd replacement and then go ahead and start looking at it. If it is as you say,
How can you make packages without reading the code, you don't know if it contains code to attack Red Hat unless you read it first..
impenetrable spaghetti, then I don't want to gain yet another unmaintainable package. Is it your position that the things that are
Take a look see what you think. Second opinions are always good
wrong with Polyaudio would be harder to fix than just fixing esd? Or perhaps there are better alternatives around? If we can find a solution that is easy to integrate, maintain and audit I am all for that.
There are several alternative sound servers such as arts (which we already ship) and lots of fun politics around some of them
Havoc Pennington (hp@redhat.com) said:
Do we have any comments on the sound server topic from a broader perspective than only GNOME?
A competing proposal I've heard is to just use ALSA directly.
Well, you'd need to set up ALSA to use dmix first. Once you do that, native ALSA usage could work.
There's also jack, arts, and other mixers of that sort. Note that mixing jack and polypaudio doesn't look like it will work right.
The fact that polypaudio's client API/ABI hasn't actually stablized at an initial version is worrisome.
Bill
On Thu, 28 Oct 2004, Bill Nottingham wrote:
Havoc Pennington (hp@redhat.com) said:
Do we have any comments on the sound server topic from a broader perspective than only GNOME?
A competing proposal I've heard is to just use ALSA directly.
Well, you'd need to set up ALSA to use dmix first. Once you do that, native ALSA usage could work.
There's also jack, arts, and other mixers of that sort. Note that mixing jack and polypaudio doesn't look like it will work right.
The fact that polypaudio's client API/ABI hasn't actually stablized at an initial version is worrisome.
The API doesn't currently provide many real benefits over esound. More specifically, it doesn't have the synchronization features that are needed for anything non-trivial. The basic idea is that to get realtime right, you *have to specify a timestamp with all commands and events*. This 'get_latency()' junk isn't useful - it's the same paradigm that we've already had with esd.
I don't know where it currently is at, but MAS (http://www.mediaapplicationserver.net/) was supposed to have the proper API for synchronization/timing/etc, based on the ideas of the old AF server. It at least compiles & runs for me. The main drawbacks are lack of ALSA support (easy enough to fix), and use of imake (also fixable). The code seems a little cleaner than polypaudio at a brief glance.
Another alternative is to use gstreamer as 'the' framework, and then create a gstreamer plugin that bridges sound to a daemon which does the actual mixing and playing. That daemon could also use gstreamer internally to perform the mixing etc. so the only really hard part would be bridging the gstreamer plugin interactions between processes. This approach should give the realtime/synchronization support needed for games and multimedia apps, but make use of all the good gstreamer work that has been done so far. It also would allow us to get rid of the sound server altogether on hardware where it isn't needed and where the user doesn't care about sound events.
NMM has been mentioned in the context of a sound server, but it seems to be almost a 'networked gstreamer in C++' concept (I assume we're talking about Network-Integrated Multimedia Middleware when saying NMM...)
$0.02, -- Elliot
On Thu, Oct 28, 2004 at 02:11:06PM -0400, Havoc Pennington wrote:
A competing proposal I've heard is to just use ALSA directly.
I wasn't aware that ALSA supported network audio. If you were going for a 'direct ALSA' type setup I'd actually suggest also stealing SDL_mixer.
- Polypaudio provides an ESOUND compatibility module. When this is enabled polypaudio emulates an esound server, including autospawning
Good
As to the code - no synchronization interface with X property changes, so you can't stream sync the tcp session with the X tcp session. Thats one of the real "doh!" problems with esd. I also can't find an accessibility interface to pass audio descriptons.
There are lots of dubious looking pieces of code that deal in terms of multiplication without overflow checks. So far they look ok but make me jumpy.
Code is hard to read with lots of pointer and pointer to pointer spaghetti most of it uncommented.
pa_authkey_load_from_home assumes the file system is shared rather than putting the auth key on the X root window. It also doesnt use getpwnam as fallback for home. Means it cannot be run chrooted.
pa_drop_root doesn't properly drop saved setuid bit on some systems. Does use capabilities which is good, although its not obvious why it actually needs any.
Uses access() which never gives the right answer to anything because its implicitly racy
I see no code trying to ensure that a lot of connects that dont bother authenticating but just wait are cleaned up quickly.
Lots of stuff like esd connection_write seem to have no sane handling for memory limits (eg when network is slower than reader)
It's got fairly dubious looking portability code (although maybe its inherited esd suckiness)
"strncpy(name, (char*) data + sizeof(int)*2, sizeof(name));"
No rate adaption
It seems very overcomplex, unauditable, lacking functionality and far inferior to arts (or to be honest in some ways to esd).
On Thu, Oct 28, 2004 at 02:11:06PM -0400, Havoc Pennington wrote:
Do we have any comments on the sound server topic from a broader perspective than only GNOME?
Is there any perspective on using arts
A competing proposal I've heard is to just use ALSA directly.
For network stuff having had a further thing I'd implement esd "second edition" by taking ESD and replacing all its audio side code with SDL_mixer, which was written by someone who has a grasp of audio processing, is portable and can mix multiple channels with fades, some effect and positioning control.
I believe this is orthogonal to something like Helix/GStreamer which would both output to the sound server, but the maintainers of those media frameworks probably care about the discussion.
Helix needs 5.1 handling too - thats a lot more fun
On Thu, 2004-10-28 at 15:24 -0400, Alan Cox wrote:
On Thu, Oct 28, 2004 at 02:11:06PM -0400, Havoc Pennington wrote:
Do we have any comments on the sound server topic from a broader perspective than only GNOME?
Is there any perspective on using arts
AFAIK the main objection is overlap with helix/gstreamer instead of sticking to sound server.
Havoc
On Thu, Oct 28, 2004 at 03:45:14PM -0400, Havoc Pennington wrote:
AFAIK the main objection is overlap with helix/gstreamer instead of sticking to sound server.
So if we just used arts as the soundserver side of things (not that arts is perfect) rather than in all its glory we'd have two stacks for gstreamer layer stuff but a single unified audio layer at the bottom and much like bluecurve some vague hope of desktop sanity ?
On Thu, 2004-10-28 at 16:02 -0400, Alan Cox wrote:
On Thu, Oct 28, 2004 at 03:45:14PM -0400, Havoc Pennington wrote:
AFAIK the main objection is overlap with helix/gstreamer instead of sticking to sound server.
So if we just used arts as the soundserver side of things (not that arts is perfect) rather than in all its glory we'd have two stacks for gstreamer layer stuff but a single unified audio layer at the bottom and much like bluecurve some vague hope of desktop sanity ?
I don't object in principle. Though as someone else said, we should be sure KDE is going to stick with arts.
Havoc
On Thu, 2004-10-28 at 22:44, Havoc Pennington wrote:
I don't object in principle. Though as someone else said, we should be sure KDE is going to stick with arts.
They're not. They're as fed up with arts as "we" are with esd. When I talked with multimedia people at DDC in Ottawa, they sounded even more desperate than we are to get rid of it.
Which makes me wonder: Alan, why do you like arts so much?
Ronald
On Thu, Oct 28, 2004 at 11:45:38PM +0200, Ronald S. Bultje wrote:
They're not. They're as fed up with arts as "we" are with esd. When I talked with multimedia people at DDC in Ottawa, they sounded even more desperate than we are to get rid of it.
Which makes me wonder: Alan, why do you like arts so much?
Its better than esd. Thats its only redeeming feature - so I certainly don't like it or hold it up as ideal.
On Thu, 2004-10-28 at 18:08 -0400, Alan Cox wrote:
On Thu, Oct 28, 2004 at 11:45:38PM +0200, Ronald S. Bultje wrote:
They're not. They're as fed up with arts as "we" are with esd. When I talked with multimedia people at DDC in Ottawa, they sounded even more desperate than we are to get rid of it.
Which makes me wonder: Alan, why do you like arts so much?
Its better than esd. Thats its only redeeming feature - so I certainly don't like it or hold it up as ideal.
He likes arts! He's a witch! Burn him! Burn!
;-)
Lets just hope he doesn't start liking Microsoft! With the exception of Halo, microsoft's best product to date aka it works and doesn't need security updates every few hours.
David
On Thu, 28 Oct 2004 18:27:03 -0400, Bryan Clark bclark@redhat.com wrote:
On Thu, 2004-10-28 at 18:08 -0400, Alan Cox wrote:
On Thu, Oct 28, 2004 at 11:45:38PM +0200, Ronald S. Bultje wrote:
They're not. They're as fed up with arts as "we" are with esd. When I talked with multimedia people at DDC in Ottawa, they sounded even more desperate than we are to get rid of it.
Which makes me wonder: Alan, why do you like arts so much?
Its better than esd. Thats its only redeeming feature - so I certainly don't like it or hold it up as ideal.
He likes arts! He's a witch! Burn him! Burn!
;-)
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
Do we have any comments on the sound server topic from a broader perspective than only GNOME?
Is there any perspective on using arts
supposedly arts is capable of a number of audio backends, even ESD. I know that it works with NAS, which has a /dev/dsp redirection library available already. so for terminals, NAS isn't a bad proposition. the one gotcha is that if you are using NAS, you need to turn the buffer just about off in the KDE control panel, or you'll get some awful skipping.
A competing proposal I've heard is to just use ALSA directly.
For network stuff having had a further thing I'd implement esd "second edition" by taking ESD and replacing all its audio side code with SDL_mixer, which was written by someone who has a grasp of audio processing, is portable and can mix multiple channels with fades, some effect and positioning control.
Oooo, I would agree with that, especially if existing esd software doesn't require much changes. Would MAS (http://www.mediaapplicationserver.net/) be a realistic possibility?
On Thu, Oct 28, 2004 at 03:27:25PM -0500, Richard June wrote:
For network stuff having had a further thing I'd implement esd "second edition" by taking ESD and replacing all its audio side code with SDL_mixer, which was written by someone who has a grasp of audio processing, is portable and can mix multiple channels with fades, some effect and positioning control.
Oooo, I would agree with that, especially if existing esd software doesn't require much changes. Would MAS (http://www.mediaapplicationserver.net/) be a realistic possibility?
Well the polypaudio author doesn't seem averse to the idea of using the SDL mixer code in his codebase either.
On Thursday 28 October 2004 16:32, Alan Cox wrote:
On Thu, Oct 28, 2004 at 03:27:25PM -0500, Richard June wrote:
For network stuff having had a further thing I'd implement esd "second edition" by taking ESD and replacing all its audio side code with SDL_mixer, which was written by someone who has a grasp of audio processing, is portable and can mix multiple channels with fades, some effect and positioning control.
Oooo, I would agree with that, especially if existing esd software doesn't require much changes. Would MAS (http://www.mediaapplicationserver.net/) be a realistic possibility?
Well the polypaudio author doesn't seem averse to the idea of using the SDL mixer code in his codebase either.
Like I said, I'm all for it. if polypaudio is network capable, and either emulate's a backend that arts uses, or provides a way to grab reads/writes to /dev/dsp it's a good thing. in regards to your statement that arts is better than esd though, not always. the "network transparency" of arts is retarded, rather than send an audio stream accross the link(compressed or not), it sends the filename to play. so in that respect, esd is infinately better. :-/
On Thu, 2004-10-28 at 15:24 -0400, Alan Cox wrote:
On Thu, Oct 28, 2004 at 02:11:06PM -0400, Havoc Pennington wrote:
Do we have any comments on the sound server topic from a broader perspective than only GNOME?
Is there any perspective on using arts
aRts will most likely be dropped from KDE by version 4. They're currently looking at gstreamer, MAS and NMM (I don't know what this last one is. Maybe someone else does?).
In #kde-devel on Freenode today: 16:46 < aseigo_work> zack: seriously, though, the best thing that could happen is that RH gets involved with the kde-multimedia discussions ... throw some effort onto the table with the project. it's really difficult to coordinate effective solutions with all the various os vendors when all the various os vendors insist on doing their decision making quietly behind more-or-less closed doors ;-)
While this list isn't really a "closed door" any more than any other public list, it seems to me that this discussion isn't really Fedora- specific. There's got to be a better place to have it.
Zack
Zack Cerza (zcerza@redhat.com) said:
While this list isn't really a "closed door" any more than any other public list, it seems to me that this discussion isn't really Fedora- specific. There's got to be a better place to have it.
There's always xdg@freedesktop.org, although this isn't really a *standard*, per se.
Bill
On Thu, 2004-10-28 at 23:17, Zack Cerza wrote:
aRts will most likely be dropped from KDE by version 4. They're currently looking at gstreamer, MAS and NMM (I don't know what this last one is. Maybe someone else does?).
NMM is similar to GStreamer (in principle), it's a project from students of the university of Saarbruchen (Germany). They just are somewhat less far in development (then again, I'm biased, so please make your own opinions here).
Ronald
On Thu, 2004-10-28 at 15:47, Ronald S. Bultje wrote:
On Thu, 2004-10-28 at 23:17, Zack Cerza wrote:
aRts will most likely be dropped from KDE by version 4. They're currently looking at gstreamer, MAS and NMM (I don't know what this last one is. Maybe someone else does?).
NMM is similar to GStreamer (in principle), it's a project from students of the university of Saarbruchen (Germany). They just are somewhat less far in development (then again, I'm biased, so please make your own opinions here).
I watched a video presentation of it. Seemed cool, but the speaker did mention that currently it had absolutely no concept of security or access controls.
It makes me quite nervous to have security bolted on after the fact.
Dax Kelson Guru Labs
On Thu, 2004-10-28 at 14:11 -0400, Havoc Pennington wrote:
Hi,
Do we have any comments on the sound server topic from a broader perspective than only GNOME?
A competing proposal I've heard is to just use ALSA directly.
A nice Fedora goal at some point would be to get all packages using the same sound setup.
Indeed, right now OpenOffice.org has support for /dev/audio and nas. nas support is clearly nigh on worthless at this stage and its existance continally niggles at me but I'd like to have something standard agreed as the clearly correct alternative to replace it with.
C.
devel@lists.stg.fedoraproject.org
-
Alan Cox -
Bill Nottingham -
Bryan Clark -
Caolán McNamara -
David Corrigan -
Dax Kelson -
Elliot Lee -
Havoc Pennington -
John (J5) Palmieri -
Richard June -
Ronald S. Bultje -
Zack Cerza