On Fri, 14 Dec 2001, Ivica Bukvic wrote: > My thought is to develop a sound daemon that would be compatible with > older apps using esd and artsd, based on alsa-server, with the > efficiency of jack, and ability to share audio resource(s) with the [...] > A joint effort would make this not only doable but relatively quickly > achievable. Imagine just how much time does each programmer waste on > implementing their own version of efficient sound signal pooling process > within their own application. Now multiply that by the number of linux
I'm afraid it is not all that clear that the sound daemon you describe is doable, let alone relatively quickly achievable. Few points I'd like mention: 1) Majority of current audio apps aren't realtime-safe You just can't plug these apps to an audio framework that is run with lowlatency parameters. And it's not possible to fix application problems on the server side. So we can either rewrite all audio apps or emulate the OSS-API. Unfortunately only rewriting fixes the lowlatency-related problems. Emulation can work, but _not_ with lowlatency parameters. 2) Combining JACK and ALSA? At least in theory it is possible to write an JACK ALSA plugin. It would be very tricky to combine the ALSA PCM and JACK APIs, but I think it might work. So 'jack_process(frames,buf)' would be replaced by a combination of ALSA poll() and snd_pcm_read/write (or mmap commit). Paul has mentioned the callback-driven design as the cornerstone of JACK, but I think synchronous execution of clients is really _the_ key feature. Of course, a callback API is more natural way to achieve it, but the wait()-then-operate() approach works, too. As ALSA has an OSS-emulation layer, this would mean that all ALSA and OSS apps would be able to communicate with the JACK framework. But we still have the problem of badly behaving apps. You could use them with jackd, but after a couple of seconds you'd get an xrun and jackd would drop your app out from the active clients list. Not an optimal solution.. But for apps that have realtime-safe audio operation, this ALSA JACK plugin would be the simplest way for JACK connectivity. 3) A lowpriority frontend server? aRts and JACK? The only reasonable solution I can think of is adding a new audio server to the framework, which would multiplex (possibly badly behaving) OSS audio streams to the JACK server. The frontend server would have to use large per-client buffers, so you'll lose low latency, but you could still use your old OSS apps without shutting down JACK. For apps like desktop sounds, mp3&ogg players, etc, this solution would be sufficient. 4) The big API debate... The real _BIG_ question is what audio API should Linux applications use. This is a difficult one to say the least. First of all this divides our little community to pieces. Paul offers the JACK client API, ALSA people want us to use the ALSA PCM API, KDE&GNOME people advocate CSL (Common Sound Layer), Gstreamer folks might prefer people to write Gstreamer components, etc, etc ... These are of course just my assumptions, so I apologize beforehand if I've misunderstood people. Anyway, at the same time, _majority_ of both audio app developers and users are not part of these groups, and just know about the kernel API, and that's OSS. Even if ALSA gets integrated to linux-2.5.x, the OSS API is still there. -- http://www.eca.cx Audio software for Linux!
