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

[Lennart Poettering]

On Wed, 09.09.09 16:14, 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.

What I wrote is actually this:

    "Do not touch buffering/period metrics unless you have specific
    latency needs. Develop defensively, handling correctly the case
    when the backend cannot fulfill your buffering metrics requests. Be
    aware that the buffering metrics of the playback buffer only
    indirectly influence the overall latency in many cases. i.e. setting
    the buffer size to a fixed value might actually result in practical
    latencies that are much higher."

i.e. it already says "... unless you have specific latency needs". The
point of this is that RT apps should of course set the buffer size,
however stuff like media players where the latency does not matter at
all should not request artificially low latencies and thus decrease
battery time needlessly.

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

This sounds good to me. Defaulting to large buffer sizes is certainly
good for power consumption.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4