Subject: Re: [linux-audio-dev] Still I cannot understand why...
From: Paul Davis (pbd_AT_Op.Net)
Date: Sat Dec 15 2001 - 16:12:59 EET
[ Re: ALSA ]
>The hard core developers on this list are "already there" so
>the best bang for bucks in my view is getting the next round
>of newbies up and coding asap.
So, you think that Apple wants to get the next round of Mac OS X audio
programming newbies writing stuff for the CoreAudio HAL (roughly,
their equivalent to the current ALSA API)? I don't think so ....
If we end up with a bunch of programs using the existing ALSA API, it
is rather unlikely that they will ever integrate together in the way
that CoreAudio or BeOS MediaKit apps do/did/will, or more
descriptively, in ways that are flexible, studio- and musician-friendly.
the existing ALSA API encourages (note that I don't say "force")
people to:
1) continue to grapple with h/w configuration
2) continue to grapple with sample format
3) continue to write apps that are based on programmatic
control flow instead of being callback driven.
I can't blame them - hey, read/write is much easier to deal with than
the ALSA poll mechanism (which is amazingly complex because it can
feature an NxM set of file descriptors for full duplex operation). But
in so doing, they perpetuate the situation we have now with esd/artsd
and others where the only kind of sharing is of an audio interface. If
you read Kai's excellent motivation for JACK (nee: LAAGA), you'll see
that this doesn't help us very much when we want to start to do more
interesting things than play an MP3 file at the same time as hearing
"you've got mail!".
The best bang for my buck would be (pick two):
1) to get a bunch of programmers to work on finishing JACK
2) encouraging as many people as possible to use a callback model
for their audio programs, either via JACK or PortAudio.
3) add a callback API to ALSA and get people to use that
>> Now, I must admit that there are aspects of this daemon stuff that I am
>> not too familiar with and am not sure whether this kind of architecture
>> would be capable of producing sample-synced and at the same time
>> low-latency output (as Paul has pointed out), so I am not sure whether
>> this would in the end be an universal solution. But even if that
>> wouldn't be the case, it could still be used to improve audio resource
>> sharing issue, while making extreme low-latency stuff something that
>> would have to be dealt with on individual basis (maybe the daemon could
>> be circumvented through a reserved high-priority thread, while still
>> offering a user-friendly way of "feeding" the /dev/dsp with audio
>> buffers in a highly efficient manner).
And I'm pointing out again: that will not work! Low latency sharing
isn't of much value by itself if the data from different sources is
not in sync. The data can only be in sync with a model that:
1) periodically waits idly for every process using the daemon to
have the correct amount of data - this will lead to
dropouts at low latency settings.
OR
2) periodically and actively tells each process using the daemon
that its time to produce (or consume) a the correct amount
of data.
If you or anyone else knows another way, please tell me, Steinberg,
MOTU, Digidesign, Apple, Propellerheads, and Emagic about it.
I also say again, and this REALLY IMPORTANT for people to understand
and know: ALSA *already* has a sound server daemon, 1 per
declared-and-used PCM "shared" device. ALSA apps need do *nothing*
except be correctly written to use the daemon - there is no difference
in using it to using a PCM "hw" device or any other kind of ALSA
device.
The problem is that most people are running OSS-API apps, and getting
those apps to use a "shared" PCM device is, while not particularly
complex, not what you'd call "trivial" (it requires an LD_PRELOAD "hack")
--p
This archive was generated by hypermail 2b28 : Sat Dec 15 2001 - 16:10:18 EET