On Thu, 17.12.09 16:54, Kjetil S. Matheussen (k.s.matheussen(a)notam02.no) wrote: I tend to the position that this could actually be considered a strength of our Linux audio stack: our low-level audio API does neither enforce fragment-based nor timer-based playback models. If you are interested in lowest latencies possibles it can be an advantage if you can schedule your audio with sound card interrupts, i.e. based on events that are directly connected to the audio playback device, instead of using system timers instead which deviate from the sound card clock and due to which you hence get a certain degree of inacuracy. So having the flexibility to schedule/mix audio the way you want is a feature, not necessarily a drawback. Linux/ALSA offers you this flexibility, Apple/MS does not. ALSA is not perfect, nothing is. I certainly have my list of issues with ALSA too, but then again, you should never forget how little manpower we actually have working on Linux audio infrastructure (I count 3 people being payed full-time). And its a simple fact that the louder people bitch about ALSA the less they really know about what the current problems of audio on linux are. We have huge complexities to tackle, and only very limited manpower. And OSS doesn't even remotely touch any of the big issues we have. Also, it might surprise many but I also believe that the audio infrastructure for pro audio is actually easier to get right than for consumer audio for various reasons: you can work in with a fixed interrupt rate, you don't have to deal with system timer based scheduling, the buffers are always very short simple FIFOs, no rewinding takes place, only fp samples, no encoded streams, the hardware tends to be more cleanly designed, the clocks are accurate and the set of hardware supported is smaller. So saying "pro audio is easy, and if consumer audio was done the same way things would work" is simply naive. You cannot blame the ALSA folks that they didn't supply you a full audio stack from top to bottom from day one with the limited amount of manpower available. Just accept that their are different layers in the stack and that different projects need to tackle them. And in the end it doesn't matter which part of the stack has what name and is written by whom. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4