20 Jun
2005
20 Jun
'05
2:20 a.m.
Christoph Eckert <mchristoph.eckert(a)t-online.de> writes:
I remember how happy I once was when I found libao to avoid the parallel
ALSA/OSS existance problem when coding a very small application that basically
just wanted to deliver output. I wonder how hard it would be to write
one library that does the multiplexing and autodetection/config parsing once
and for all, and maybe also auto-wrapped the callback/vs/push model
situation in both directions, such that an application could choose
which model it wanted? New options on the planet could then in the future
just be added to this layer. Some global library config would allow the
user to define default output devices and maybe even do more sophisticated things
like passing backend specific parameters for a specific program...
What's the
current "coding standard" for consumer audio
apps that should work in both
KDE and GNOME enviroments ? Use ALSA directly, support both
artsd/esd etc ?
that's the problem. Currently there's no "standard", but
creating one would simplify life a lot for developers of any
kind of audio output as well as for the BOING.WAV users.
Currently a developer who wants to make an application
straightforward needed various output plugins (OSS & ALSA
direct access, esd, arts, gstreamer and JACK). Then an
autodetection needed to be added which checks for the most
suitable output plugin. No developer will do this, because
it's very much work. BTW: For me ALSA direct access (and therefore blocking
the
device) seems to be a bit ugly for a multitasking and multi
user operating system like linux is. Is ALSA direct access
really an option (regardless that DMIX can help with this)?
I use it all the time since I own an SB Live!. On one other box I occasionally
do work on I have one of those evil non-hardware-mixing cards, and it iritates
the hell out of me that I can no start jack while the stream from
my local radio station is running.
An desktop independent soundserver available on each
linux
machine could help a lot. JACK could be a possible solution.
Why can't ALSA solve this once and for all somehow? It seems a bit of
an overkill to have a full-fledged soundserver running when something
like dmix could also do it? (BTW, have to try dmix now, really...)
What I mean is if you have your soundserver, you are still left with
rewritting every single app you ever want to use to use the soundserver,
otherwise the problem still remains. There are a hell of a lot of tools
around that use either plain OSS or direct ALSA.
--
CYa,
Mario