ALSA lib application compatibility [was] Re: mixer device

[Manuel Jander <manuel.jander@mat.utfsm.cl>]

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.

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.

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.
The cost of allowing any parameter value is not worth it in my opinion.
Its actually causing a lot of trouble.

Well, i don't ask for changes in the ALSA API, but for teaching
application developers to -please- be polite to the ALSA drivers, and to
take into account the possible restriction they apply.

Best Regards

Manuel Jander




-------------------------------------------------------
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