Re: ALSA lib application compatibility [was] Re: mixer device

[Takashi Iwai <tiwai@suse.de>]

At Tue, 18 May 2004 09:30:54 -0400,
Manuel Jander wrote:
> 
> Hi,
> 
> On Tue, 2004-05-18 at 15:46 +0200, barat@medien.uni-weimar.de wrote:
> > On Thu, 13 May 2004, Adam Tla/lka wrote:
> > 
> > > On Wed, May 12, 2004 at 05:40:55PM +0200, Clemens Ladisch wrote:
> > > 
> > > ALSA is complicated and we have no good manual describing proper use
> > > of its api. You can easily prove this: many programs have ALSA output
> > > modules but they are working worse then when using OSS.
> > > For example mplayer with OSS synchronizes video and sound much faster
> > > in case of network streaming. XMMS is broken too.
> > ?? mplayer isn't broken in any way with alsa. it supports alsa since the 
> > early days and also current versions very well. please don't talk 
> > bullshit.
> > it probably does av-sync faster at some particular streams (what ever you 
> > mean with that) with oss, but i never ever saw some significant 
> > performance differences compared to oss.
> > at least it supports real mmaped-io for up to 2 channels.
> > 
> 
> Unfortunately i have to agree with Clemens. In my opinion the ALSA API
> is giving the applications too much freedom in choosing parameters and
> does not enforce any restrictions on hardware that can't support them.

basically, such a restriction is up to the driver.  in the ideal
world, hw_constraints should be able to handle these cases
properly...

> As the main author of the Aureal Vortex driver, its very stupid having
> to handle arbitrary period sizes, introducing a lot of overhead and
> complexity in the driver, while the hardware just is not designed to
> handle period sizes that are not powers of two, due to page boundary
> overlapping trouble. Obviously as a result, OSS works much better, since
> it almost ever chooses the biggest buffer possible, resulting in a sane
> period size. Period sizes of 314.15.14 bytes are just silly, plain
> stupid. The user won't notice any difference if its 256 instead, but
> since the app insist in such period sizes it just fails, and the user
> gets no sound all. The behaviour of the user application in the end
> depends too much on the hardware it is running on.

first, the power of two is not a golden rule for every sound chip.
for some chips, it's difficult to handle such period/buffer sizes.

in theory, we can set the hw_constraint for the buffer/period sizes in
power of two.  yes, i tried it, but it failed.  this is because ALSA
handles the buffer/period sizes in two different units, frames and
time in msec.  IMO, it was a wrong decision to use different units for
the single purpose.  maybe we need a workaround not to mix up these
units in the configurator.


> AFAIK, the ICE1712 has exactly the same hardware restriction. I know
> that the via driver does cope with this, but that particular hardware
> has special hardware resources for such a thing, where other hardware
> don't.

ICE1712 has no problem regarding this.  its problem is that the
max. buffer size is 64k even though it always uses 32bit x 10
channels.

> The cost of allowing any parameter value is not worth it in my opinion.
> Its actually causing a lot of trouble.

not all parameters are accepted.  it depends on the driver
implementation.


please don't misunderstand:  i don't mean that the current ALSA design
is perfect.  it's not at all, as you know :)
however, the basic design of ALSA is that it leaves such a
reststriction purely to the driver implementation.  if your driver
allows everyhing, it's the driver's responsibility to support
everyhing.

unfortunately, the power-of-two restriction doesn't work well because
of the failure of configurator.  it's an exceptional case.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click