[alsa-devel] Problems with safe API and snd-cs46xx
superquad.vortex2 at gmail.com
Thu Sep 10 10:47:14 CEST 2009
Is "one period per buffer" really work ?
There are quite a few drivers which has "periods_min = 1" (e.g. emu10k1,
however aplay did not like this
"Can't use period equal to buffer size (%lu == %lu)")"
2009/9/9 Takashi Iwai <tiwai at suse.de>
> 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
> > > > > > didn't before. However, using mplayer with the "-ao openal"
> > > > > > still doesn't play correctly - in fact, it sounds the same as
> before -
> > > > > > so it looks like OpenAL is actually doing things slightly
> > > > > > than I thought. :/
> > > > >
> > > > > Yes, likely. The app like openal is usually more sensible
> > > > > 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 :)
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
More information about the Alsa-devel