17 Dec
2009
17 Dec
'09
12:46 p.m.
On Thu, 17.12.09 16:54, Kjetil S. Matheussen (k.s.matheussen(a)notam02.no) wrote:
Okay, I didn't know that. But this is still no
reason why ALSA
shouldn't take care of mixing/scheduling/etc.
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.
by itself plus providing low-latency performance (with
mixing) when
that is required. Leaving out mixing to third-parties, plus exposing
a very complicated low-level API and a complicated
plugin/configuration system (which probably has taken a more time to
develop than implementing a proper mixing engine), has created lots
of chaos.
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