[alsa-devel] Problems with safe API and snd-cs46xx

[Takashi Iwai]

At Wed, 9 Sep 2009 16:07:35 +0200,
Lennart Poettering wrote:
> 
> On Wed, 09.09.09 14:35, Takashi Iwai (tiwai at suse.de) wrote:
> 
> > > I can confirm now that Audacious does indeed play correctly where it
> > > didn't before. However, using mplayer with the "-ao openal" switch
> > > still doesn't play correctly - in fact, it sounds the same as before -
> > > so it looks like OpenAL is actually doing things slightly differently
> > > than I thought. :/
> > 
> > Yes, likely.  The app like openal is usually more sensible regarding
> > latency, so "safe API" described there wasn't appropriate at all.
> 
> Hmm, so are you suggesting I should change that little text about the
> safe API subset I wrote?

Maybe a bit more addition would be helpful.  The realtime apps do
care the latency.  So, obviously it's not the target of your
description.

> So, users should always set first the buffer size, followed by the
> period size, is that correct?

Yes, in general, this order gives more chance for a larger buffer
size.  But, if you specify both buffer and period sizes, there
shouldn't be much difference.  Specifying the buffer size is
especially good if you don't give any period size.

The situation is improved now with 1.0.21a since I changed the
determination order in alsa-lib.  You'll get the largest buffer size
as default with 1.0.21a (let's see whether this gives any regressions
;)  But, if portability matters, setting thebuffer size would be
safer.

>  And if that fails, try the other way
> round, and if that fails set buffer size only? And if that fails set
> nothing?

Yes, this sounds reasonable.


thanks,

Takashi