Subject: Re: [linux-audio-dev] Still I cannot understand why...
From: Paul Davis (pbd_AT_Op.Net)
Date: Thu Dec 13 2001 - 07:12:36 EET
[ ah, here's that message i missed ... ]
>So what is preventing us from taking CoreAudio-like path and reworking
>the way audio is handled OS-wide?
CoreAudio has explicit kernel-side support in MacOSX. I find it
unlikely that this would ever be accepted by Linus. We have plenty of
mechanisms to make this fast. khttpd was a tiny piece of code that did
something that a huge %-age of all linux machines do, and Linus was
still very opposed to it to start with. I can't imagine how he'd react
to what is clearly a user-space framework being moved into the
kernel. There's nothing that CoreAudio does that needs any new Linux
kernel support. I can't see anything gained by moving it into the
kernel other than "forcing" it as the standard, and for that, I'll
just be glad when ALSA becomes the "forced standard" (though of
course, it won't be because the OSS API will still be
supported. sigh). There's another example - look at how difficult its
been just to get ALSA to replace OSS in the kernel.
> Is this just a gargantuan task or is
>it just lack of interest? No one said that we need to stick to the OSS
>standard established way before anyone even considered Linux as a
>multimedia workstation.
As I said, CoreAudio requires a different application design unless
you only use the CoreAudio HAL, which plays a role analogous to the
one ALSA plays for us. If everyone was willing to port their code to
this application design, either by moving to JACK or PortAudio, we
could move forward. Otherwise, its an impossible task.
>On the other hand, you have mentioned alsa-server. I must admit I do not
>have much knowledge regarding this one. Is this server capable of
>providing daemon-like audio resource sharing and keeping latency low? If
>so, maybe this should be the core framework for the new daemon?
it provides daemon-like audio resource sharing.
as i mentioned previously, low latency is generally not much use
without sample synchronous execution of all participants in the shared
tree. alsa-server does not do this.
>If there is a better solution to this problem than what was originally
>established by OSS, shouldn't we learn from our own mistakes and other's
>successes (i.e. core audio and BeOs) and rework the way audio is handled
>in Linux?
JACK is an attempt to do just that. If more people would contribute to
it, which at this point means being willing to understand how it works
and write code to fix problems and implement features, we would have a
working framework.
Abramo has told us that ALSA can do this. He's mostly right. ALSA does
offer a totally unified approach to audio and MIDI. Its missing one
important feature right now, however, and thats sample-synced
execution of a processing "graph" (consisting of several
applications). Actually, make that 2, since its also missing inter-app
audio routing, but this can be solved much more easily than the
sample-synced issue.
Any framework that does not ensure sample-sync execution is
ultimately useless for anything "studio-like". It means that you will
get strange comb-filter-like effects as two different audio streams
move in and out of phase with each other by a few samples.
>Could you please tell me how hard would it be to rework the way audio is
>handled, while preserving existing compatibility with esd and
>artsd-based apps, and on top of that providing JACK-like efficiency
>(with priority managing capability)?
JACK is 60% about sample-sync, 35% about inter-app audio data routing
and 5% about low latency (you can happily run a JACK server with
massive latency if you choose).
As I've tried to explain several times, callback-driven sample-sync
operation is a different design than "block on read/write". You can
make apps that use the latter design work with a sample-sync network,
but they don't participate in it as equals (i.e. they are not
sample-synced to the rest of the network).
Thats why getting alsa-server to participate in JACK would be great:
this would allow all regular ALSA apps to use JACK without its
sample-sync features. The other way around doesn't work: all the
sample-sync-needing apps would fail to get what they
wanted/expected/needed if they just use alsa-server.
--p
This archive was generated by hypermail 2b28 : Thu Dec 13 2001 - 07:09:22 EET