[MPlayer-dev-eng] audio_out.c question

Adam Tlałka atlka at pg.gda.pl
Fri Mar 24 08:37:29 CET 2006


On Thu, Mar 23, 2006 at 07:19:14PM -0500, Rich Felker wrote:
> On Thu, Mar 23, 2006 at 03:53:22PM -0500, Mitch Golden wrote:
> > I guess this is a question for Rich - is the concern one of principle that 
> > you feel that no OS should mix the sound in software, or is it a concern 
> > that alsa in particular has bugs?
> 
> The principles are:
> - the application should not need to use libraries to access sound.
> - a library should NEVER do anything that alters the state of the
>   calling program.
> - software mixing is a bad idea because it's impossible to synchronize
>   correctly, bug-prone, etc.
> - a well-designed api that conforms to the unix philosophy for
>   hardware access and which is standard across all unices which
>   support sound should not be replaced by a bloated, buggy,
>   windows-inspired, linux-specific api (ALSA)

I agree with Rich here.
Instead of improving OSS in kernel or doing some kernel to mixing daemon
protocol so all will be transparent to apps we have additional userspace
library solution. More then this mixing in cases where hardware
mixing is impossible is done behind apps back as a separate library
thread using signals.
This approach leads to bad sound effects especially in case of high
load. Additionally it doesn't work at all in case of apps which for some
reasons disables signals :(.

Anyway non-free version of OSS drivers is doing input and output mixing,
resampling and additional 3D sound expansion in software if sound card
doesn't support it. It is done in kernel space and this is completly
transparent to apps. For private use it is free of cost.
There was even a letter on ALSA list from main non-free OSS developer
saying that they plan to release freeware restricted version of
their OSS drivers. So it looks interesting...
Their drivers works with latest 2.6.16 kernel without problems for me.

So from my point of view OSS-free drivers should be improved if we want
completly free drivers. Jack and other daemons are no so bad solutions
but they can use kernel drivers directly (in case of OSS) so we don't
want and need addtional ALSA lib here. There are some security problems
with jack (it is a RT process and can raise priority of its clients).
Rewritting apps to use it is a waste of time IMHO.
Unix devices and transparent from app point of view approach
is the best and the most compatible method. All other looks like
wasting of programers time and system resources and in case we buy
hardware mixing cards (or mainboards with better audio hw) can be thrown away.
Changeing default audio device probing has no sense in this context.

Regards
-- 
Adam Tlałka       mailto:atlka at pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group       - - - ~~~~~~
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka at sunrise.pg.gda.pl




More information about the MPlayer-dev-eng mailing list