>> ALSA is *a* sound library. There are lots of things that it doesn't > >I would really say: ALSA is *the* sound library (at least on Linux). Isn't it >in kernel >2.5+ ?
alsa-lib isn't in kernel 2.5, because its not part of the kernel. alsa-lib doesn't contain any code to read or write audio files, for example. it contains no code to do dithering. it contains no code to do audio rate resampling, at least no code that is accessible by a regular program. >I don't know if I get the point right here, but it reads: don't use >ALSA. But it's the only sound library that will be delivered with all >distributions in future, so what choice do mainstream application >writers have ? OSS ? PortAudio would be a much better choice. >So you discourage use of ALSA because it suggests/allows a >non-professional programming paradigm? not just non-professional. the read/write paradigm isn't just non-professional, its wrong. its masking a fundamental aspect of the hardware. it works for video (which is also, essentially a real time streaming media device) because nobody notices anything odd about a video screen that doesn't change for a little while (unless they are trying to watch a real-time video stream). but any audio device that outputs the same data twice around its hardware buffer is immediately noticeable by any (non-hearing impaired) user. you can't fake this. apps that use large buffers are just getting away with pretending; it may work for them, but it doesn't work for most apps. i find the lag on the xmms eq controls, for example, quite irritating. >> the APIs that are used to write almost all audio software code in >> production these days all use a callback model. > >Sorry for questioning this statement. Of course we all don't have any statisti >cal data but >you miss what I see as the majority of applications that use audio devices: > >1) games >2) media players >3) GUI sounds (i.e. accessibility) this is a fair point. i apologize. i have my head so far inside the "audio software for musicians" box that i tend to fail to see such applications :) however, the very fact that the applications developers of such programs really don't know much (if anything) about audio programming, and probably don't want to know much about it either, suggests that an API like ALSA which exposes the full HAL is probably a mistake. again, i consider PortAudio a vastly preferable solution. i would note in passing that your second class of apps might very well be something that needs to be integrated with prosumer/pro apps. the division between, say, alsaplayer and gdam (to give two examples from the linux world) is hard to find when thinking up reasons why one should never be useful as a participant in something like JACK, and another one should. >> porting from the o/c/r/w model to the callback one is >> hard. do you want another generation of apps stuck with this problem? > >So you think the solution is to lead developers to the right programming parad >igm by not making o/c/r/w type of APIs available anymore. pretty much, yes. >Again, I don't see the point. The 99% of Linux users using the above >types of programs do not care about the programming paradigm. They >want to hear their apps. Since L inux distributions enable artsd/esd >sound daemons by default, people don't hear app lications that don't >support the specific sound daemon. On Windows, we do have the choic e >and it all happily coexists. you're talking about a world in which there is a sharp divide between the classes of apps you've listed above and the prosumer/pro apps i tend to focus on. i'd rather see linux support audio APIs that provide, if not an integrated user environment for all apps (this may not be possible), then an integrated and consistent audio API, one that recognizes the inherently real-time nature of audio software and uses a callback-driven model. can you say "CoreAudio"? :)) >Well, my point is that I want mainstream apps work out-of-the box, no >matter i f they talk to a daemon, to ALSA or use OSS. For semi-pro >audio apps, a little effort to m ake them use the full capabilities >is necessary anyway, and those people probably won't mind stopping a >sound daemon. Apple have done the right thing, IMHO. OS X forces developers to either (1) deal with a full featured and complex HAL, but in so doing lose the ability to interact with other software, which users won't like or (2) use the AudioUnits API (callback based) which allows full integration. The problem is, as I noted several times before, there is nobody in the linux world who can force this on developers. --p ------------------------------------------------------- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
