Re: [linux-audio-dev] Still I cannot understand why...

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Still I cannot understand why...
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed Dec 12 2001 - 01:40:43 EET


>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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Dec 12 2001 - 01:39:23 EET