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

[Takashi Iwai]

At Wed, 9 Sep 2009 16:27:17 +0200,
Lennart Poettering wrote:
> 
> 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.

Well, basically this belongs to the implementation detail.
Unless you have a solid RT kernel, the latency can't be guaranteed.
The old good way to achieve the smooth playback is to use the large
buffer with the small periods.  Then you have a better chance to be
woken up before buffer underruns.  That's how the ALSA default setup
is done, even with the latest version.

Of course, in this scenario, the battery life wasn't taken into
account.  If you care the battery life, too, the simplest solution is
to have two periods in the largest buffer size.  But, this doesn't fit
with every programming model, too (imagine an old app that don't do
multi-threading :)


Takashi