>In the beginning there was esd, and unfortunately, it still is... It is >a latency hogging daemon which requires application compatibility to >work and is yet to be replaced by something better... > >Then, we had (and still have) somewhat "bloated" Arts which was >originally designed to do something completely different and currently >offers very little to write home about (granted, it does what it's >supposed to, but offers no platform-wide compatibility, neither yields >great latency results). > >Finally, we have JACK, which does very well in the latency department, >but it is again something that has to be incorporated into the app in >order to work, so has no ability to act as a system-wide highly >efficient sound daemon. Neither does it solve the issue of hogging the >/dev/dsp resources (please correct me if I am wrong). > >Any my question is simply why?
The original audio API for Linux (OSS) was based on the standard unix open/close/read/write paradigm. This model has encouraged application designs that doesn't allow for certain things. If you want no app (re)design, use esound (GNOME does) or artsd (KDE does) or alsa-server (we hope many people will) and be happy. They work. alsa-server in particular is quite promising, since apps do not need to be rewritten, the code is clean (thanks, abramo!) and there is lots of opportunity for customization and configuration when needed. HOWEVER: If you want low latency *and* sample synced operation, you've got to accept that it requires a different design for applications. Thats why all the plugin APIs (VST/DirectX/TDM/MAS/RTAS/etc). and Mac OS X CoreAudio and the BeOS MediaKit use a different design. JACK is not an attempt to replace esound/artsd/alsa-server. Its an attempt to provide facilities that they cannot. >It is obvious that if we put a lot of effort into a single high quality >sound daemon, the sharing of dsp resources between different apps at the >same time would become a breeze, meaning that this problem would not >have to be circumvented every time someone chooses to write a new audio >app for Linux. Well, IMHO, Apple have taken the right path with CoreAudio. But CoreAudio offers things that esound,artsd and alsa-server do not, and cannot. In exchange, CoreAudio requires a certain kind of application design. JACK can offer these things (and does, modulo some ongoing development issues), and likewise requires a different application design. What type of system do you want? If latency is not important, which its not to most "audio apps for linux" (they are typically of the xmms genre), esound is fine, artsd is cleaner and alsa-server is even more elegant and much more general purpose. If the kinds of facilities offered by CoreAudio (or ASIO+Rewire to give a different example) matter to you, then you've got to use the right architecture, and apps which understand and participate in that architecture. >Maestro M3) is not capable of mixing multiple streams of incoming sound >due to this limitation, and I honestly do not have time to learn the >whole ALSA API and then learn a month later that it has completely >changed... this has not happened with ALSA in many months. this was a problem, yes, but its not anymore. --p
