>I'm interested in whether there has been any large scale discussion >about a unified approach to sound support. Right now supporting >oss/alsa/arts/esd see ms a bit much and I'm curious as to whether >there has been any talk of establishi ng something like sound >server(arts)->sound driver(alsa)->hardware, with common interfaces >established for the sound server level and sound driver level. The >only thing I've found so far are discussions of csl and I'm curious >as to whether csl is adding one to many layers to the whole scheme.
there has been some discussion about this. you sound as if you do not know that it is believed that ALSA will soon replace OSS in the kernel sources, removing OSS from its position as the default audio API for linux. audio servers: the problem is that different people need different things. most desktop users would be quite content with the type of service that artsd provides, which is why both KDE and GNOME appear to have adopted it for their desktop environments. but neither artsd nor esd are suitable for "semi-pro" or "pro" audio applications because of their latency characteristics. ALSA has its own method of providing shared access to devices, which has the benefit of being usable without any run-time hacks and with the exact same API as any other ALSA PCM device. However, it too is not suitable for high end applications. Neither the ALSA shared access system nor esd provide inter-application audio routing either, something most of us consider very important as we move forwards. a recent move toward fixing the high-end (read "real time, low latency, high bandwidth") situation can be found at http://jackit.sf.net/. this aims to provide functionality similar to that offered by CoreAudio on OS X, or viewed differently, similar to the role played by VST with Cubase, Nuendo, Logic and others. However, all these systems (CoreAudio, VST, JACK) require very different program designs from those typically used by people who write audio applications for Linux. There is a little bit of momentum toward adopting JACK, but so far only alsaplayer, ecasound and very soon, ardour and rythmnlab, are using it. so, its a bit of a mess. IMHO, it would be idea if ALSA provided or even enforced an API like the one imposed by CoreAudio. but it doesn't, and so for the time being, its quite possible to continue writing applications using a variety of APIs that all allow the old habits of "block on write/read" and/or "single threaded design" to continue. i wrote to the authors of CSL to ask them to reconsider what they were doing, but got no reply. there is nobody within ALSA working on moving ALSA in the direction of a CoreAudio-like API. in short, there is no relief in sight. --p _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
