On Mon, Jan 21, 2008 at 10:04:54PM -0500, Paul Davis wrote: > ALSA is going to vanish as an API for all but those developers who don't > know how to use google. Pulse even has plans to "replace" JACK one day, > but its lead author fully understands the challenge there.
The only parts that will remain are probably the hw: devices, which generally work well and provide the low-level access that you need to build things like JACK on. The _technical_ reasons why dmix/dsnoop apparently can't be made to work as expected remain a mystery to me. It's not because 'this can't be done in user space' as has been said IIRC on the OSS author's blog. JACK does it in user space. Maybe the project has fallen victim to it's own ambitions of providing all sorts of everything to everyone - a range of access methods (mmapped, blocking, non-blocking, callback,...), and the whole collection of soft devices it can create to keep everybody happy. I guess that in the end the number of possible combinations just exploded and became to large to handle. Organising things this way was IMHO a bad idea. Instead of trying to anticipate each and every type of device an application writer would ever want to talk to, it seems safer to provide just a single interface, which should be close to the hardware, and then a number of libraries (instead of the preconfigured soft devices) to help applications to convert to whatever they want, providing things like e.g. sample rate conversion, easier non time-critical access, etc. Also, if the audio hardware has to be shared, then no single app that just happens to produce some sounds should _ever_ have been allowed to think it could configure the hardware, to select sample rates or formats. Just as normal apps are not expecting to be able to format a disk, or to configure the network interfaces. Part of the blame is with the authors who insisted on being able to do such things, even if the primary function of their app was not related to audio at all, just because it was easier. There are other problems of course, one of them being documentation about the *design* of the system, not just the API. I once tried to debug an ALSA driver, but had to abandon the exercise. Almost everything in the drivers seems to be done by callbacks and endless levels of indirect calls via function pointers that are initialised in dark places, and that makes it very difficult to understand what's happening, and where. The only way out (or in, for a driver developer) is system design documentation, which is non- existing AFAIK. I haven't looked at OSS for a long time, not since the first ever LAC presentation I heared was the one by Takashi, on ALSA. But I will look at it again, even if for most of my work it's not really relevant - JACK rules. Caio, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa. _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
