Are There Replacements for EsounD? 14
An Anonymous Coward asks: "On the development roadmap for GNOME 1.4 and 2.0, EsounD is listed as becoming an optional package. Are there any functional replacements for ESD on the horizon? Is an overhaul to the ESD code base underway? Are there plans to make a common sound daemon interface between KDE and GNOME?"
We need a x-platform sound playing/mixing daemon (Score:1)
I want seamless mixing of two sound sources or 10 if there's 5 users listening to mp3s and system sounds logged into one box that has multiple monitors and keyboards or works as a server for diskless clients, say. Plus the "sound server" should play all system sounds in OGG/Vorbis format. Ogg/Vorbis should become the new default sound format!! (like PNG has become almost a default graphical format for icons etc).
I'd like someone using an client app on my server to have system sounds triggered on their machine's Vorbis sound server subsystem thingy - if they have a sound server running on their machine (note I'm adopting the X terminology). I wouldn't want my server to stream sound to just anyone but I'd like it to be able to
I know there's NAS but it needs an update and some new features to play well with the latest in sound audio technology.
Re:Well what's wrong with esound? (Score:2)
2) It's a minor thing, but it can't handle 48 kHz audio. It won't complain, but it'll sound like shit.
Because the API sucks. (Score:2)
But to implement it right, you need a matching esd_get_stream_pan() so that the program doesn't get confused as to what its current volume setting is. Instead you have to get an entire config structure, pass it through another function, and so on and so on. (I haven't looked at the code in a long time, but getting the pan settings was FAR harder than setting them.)
You ever notice that OSS/Alsa only allow 1 sound? (Score:2)
ESD is also a mixer. It lets you play lots of sounds simultaneously. This is a good thing, as it means playing an MP3 isn't going to kill my ability to receive AIM notifications, or other similar things.
--
Ben Kosse
From the horse's mouth... (Score:2)
Esd was fundamentally designed just to handle making "plink" noises (window managers, IM clients, short term audio feedback in programs)
without interfering with mp3 players, live audio strems, internet telephony, or other "long-term" audio streams. If I could feed the audio into cthugha, all the better. These jobs it performs adequately.
I never intended for esd to be The Master Audio Control Program. If you have hard, real-time, guaranteed nanosecond response time requirements, *no* audio library that allows concurrent software access to the audio card (no guarantee that an audio card supports hardware mixing) will suffice. Such a program *needs* to talk to the bare
hardware at the lowest level possible. Fortunately, the need for such programs on a "standard" desktop machine is minimal. Esd can still support such programs, however. See the esd_standby() and esd_resume() functions. Don't want esd hogging the sound card? At least I let you take it out of the loop.
It is also some sign of acheivement on the part of esd that Lokisoft's games, and RealPlayer 7.0 support it "out of the box". At some point,
it just became easier to make it a program option, rather than a paragraph in a FAQ. Now if we can work on the Id guys...
But wait. Quake requires memory mapping the audio card's DMA buffers. Transferring data between esd client and server goes through a unix
domain (or tcp) socket. This should just be a memory copy on any reasonably optimized network stack, but might not be the case. By converting the server to using a shared memory buffer, as a circular data buffer with read/write pointers (and audio format metadata) within the buffer, we can avoid the data copy entirely. Someone suitably
devious could even update esddsp to wrap the OSS calls that return samples written, read/write locations within the DMA buffers. Voila!
esddsp q3arena! And you still get your IM chimes.
Think the interface to esd sucks? Why yes it does! With the shared memory transport, the standard api will need overhauling anyway. Esdlib should never have ever returned the raw socket id to the client program. That should have been a pointer to an opaque EsdConnection structure.
Live and Learn. C++ would also have arguably been a better choice for the server; at least would have made certain parts of the code a *lot*
cleaner. Live and Learn.
But wait. The mixing/resampling engine sucks. Grab a GPL'd mod player (e.g. http://xmp.home.ml.org) and "reuse" the engine in esd. It can be done. Someone sent me the patch a year ago, and my hard drive ate it. I never heard from them again. (sorry, whoever you were).
Yes. Esd sucks, but until another option arrives that generates *remotely* the same amount of stupid questions to application *writers*
(i.e. Loki, Real, Id, all the K's of programmers who ever answered the question "why doesn't your program work under Enlightenment/Gnome?")
esd is (I shudder to say it) the *de facto* audio server standard on Linux. Esd also runs on a wide variety of other Unix platforms, and can serve as a copatibility layer. Sad that my pathetic excuse for a couple months of boredom has
caught on so well, but there you have it.
I still accept patches, once every month or two, I even apply them.
Good and bad sides of esound (Score:2)
One of the things newbies don't like about UNIX is the thing the get under windows. Typical examples of this include inconsistent user interfaces, lack of completed good GUI software, and problems using audio from more than one source at a time. OSS has done some to fix this, with it's virtual mixers, but it has shown itself to be less than stable for a lot of users, and it's also not a free package.
Esound has done a lot to improve on this, but allowing users to easily configure their UNIX systems to play audio from more than one source at a time. It migth not convert every windows user, but it's one of those things that make everyday life a little better.
If you're thinking "so what? that's not the issue here" then you're entirely right. The issue isn't if esound is a bad product, it's more a question of can we do better?
Esound has had it's problem over the years, including some rather scary security issues. The audio bits themselves seems fine, and esound has helped a lot in providing the UNIX world with a generalized interface for audio playback and recording.
For this reason I think a possible good solution would be to keep the interface to esound, while revising the entire package. The audio bit seems fine, but the rest of the package could use a workover. A good place to start would be to throw away all the interface code, go back to the design level, look at how to design the internal parts of the system. Good separation from the rest of the system is vital to make it a secure package. One place to start would be make the daemon run under a highly limited user id, with access to the audio device.
The rewrite of the interface code should be done with the clear knowledge that users are potential evil people who might send bogus data in attempts at exploiting flaws in the system.
The API which programs will call could with clear benefit be kept backwards compatible if the developers don't see any problems or limitations with that. As a alternative there's always the wrapper approach.
Esound Should be _REMOVED_ (Score:1)
Although Esound is another another abstraction, its a poor one. On my computer, playing sound through the OSS layer works fine.
Once esd gets running, however, even really short sounds have a tendancy to hiccup.
Example
OSS: "Hi my name is Linus Torvalds..."
Esound: "Hi my-my-my n-n-n-n-am-e-e-e i-i-i-is Lin-in-in-in-us-s-s-s-s T-T-T-or-or-or..." (you get the idea).
Why do we need ESound? The OSS layer works fine. Just have Alsa and OSS come up with a common sound.h that allows them to do their thing. esd.h (or whatever it is) can be changed to wrap around that so nothing Gnome is broken until everything is fixed to use sound.h.
Standards are good. Adding an extra daemon just to do what OSS does already is pointless. At least, IMHO.
--------------------------
Re:Esound Should be _REMOVED_ (Score:1)
I don't know anything about sound processing, but I would figure you could do some kind of output stream meshing...a bitwise of two raw sound outputs, perhaps?
--------------------------
Re:Esound Should be _REMOVED_ (Score:1)
Plus, what is the advantage of having a sound daemon? Seems like just extra overhead....
--------------------------
alsa, and OSS aren't as cross-platform as ESD (Score:2)
Re:Do we really want to get away from a standard? (Score:3)
________________________________________
Re:Esound Should be _REMOVED_ (Score:1)
Re:We need a x-platform sound playing/mixing daemo (Score:1)
As for using OGG Vorbis everywhere, yea, I like the standard, and I want to use it (when it is finished) but for system sounds, have you any idea how much system time that would use, ok, it might be nothing for a PIV-1GHz, but for a P-166 it takes most of the system time to play OGG Vorbis, please don't forget that before moving everything to OGG Vorbis.
Do we really want to get away from a standard? (Score:4)
Tell me what makes you so afraid
Of all those people you say you hate