Re: The ALSA Situation

[Takashi Iwai <tiwai@suse.de>]

At Thu, 11 Nov 2004 10:23:44 -0800 (PST),
Linus Torvalds wrote:
> 
> On Thu, 11 Nov 2004, Takashi Iwai wrote:
> > 
> > Oh, that's hard to tell what should be the "default" parameters.
> > This strongly depends on the board.
> 
> Which is exactly why apps should not even try to set them.
> 
> My point is that the driver can select some default parameters, and then 
> users just use them by default, and thus there are no issues of 
> synchronizing between them.

The parameters a board supports are not unique.  For example, suppose
a card supporting 8bit and 16bit samples.  An app using 8bit format
ran once, then you want to play an mp3 after that.  Should the driver
keep the last 8bit format?  Or, the driver shouldn't have accepted
8bit (thus convert it in software - i.e. no mmap) even though it's
natively supported?

So, the minimal setting such as the sample format, rate, channels, etc
are still required to be set by applications although I agree that the
configuration of buffer/period sizes can be more simplified.


> > ALSA tries to provide as much function as possible.  This results in
> > variety of configurations, i.e. the famous complexity.
> 
> That may or may not be a valid excuse.

Agreed :)

> Complexity also often arises from bad decisions. And the decision to only 
> have one user open at a time appears like a pretty fundamentally bad one.

If you mean the blocking behavior, I agree.  I myself don't like it,
too.
But, solving the concurrent access in another way in the *driver
level* (the intermediate buffer or the soft-mixing) doesn't sound good
to me.  It brings more complexity than the simple -EBUSY strategy.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click