Subject: RE: [linux-audio-dev] Still I cannot understand why...
From: Ivica Bukvic (ico_AT_fuse.net)
Date: Wed Dec 12 2001 - 04:49:09 EET
So what is preventing us from taking CoreAudio-like path and reworking
the way audio is handled OS-wide? 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.
Maybe we could build a new architecture based around Alsa which,
according to what you have said, should reach its final stage rather
soon. Then we would not require the redundant re-implementation of
sound-sharing daemons, which by their mere existence add to the latency
issue.
I understand what you are saying but that still seems to me a roundabout
way to solving the core of the problem. My thought is if we already have
a capability of low-latency interaction between apps via JACK, we should
rework it so that JACK becomes a powerful kernel daemon which would be
capable of routing signal however we wanted it independent of apps (and
maybe allowing extremely low latency to be routed through when requested
[maybe by having a priority stuff established, so that the every-day
blips and beeps which are used for desktop sounds can use low priority
stuff, or can even be pushed around if needed], i.e. in the case of
Ardour).
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?
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? Isn't the BeOS at this point open source? Maybe we could hack
their code and use that as a foundation? It seems to me that OSS's
original conception of audio on Unix machines was to provide limited
audio capabilities (i.e. so that computer can play blips and beeps when
needed), so if that is the case why are we still trying to push this
architecture way beyond its limits?
If our existing ways of handling audio resources are outdated or
inefficient, we should then reconsider the foundation of our audio
architecture and improve upon it based on what we have learned?
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)?
I am still not convinced that avoiding the heart of the problem by
providing roundabout solutions will get us far. If we want to have Linux
as an audio powerhouse, as well as provide efficient environment for
development of audio-related applications, maybe we need to get rid of
the elements that are stalling our progress...
Interesting comments. Keep 'em coming :-)
Ico
This archive was generated by hypermail 2b28 : Wed Dec 12 2001 - 04:44:01 EET