Is "one period per buffer" really work ?
There are quite a few drivers which has "periods_min = 1" (e.g. emu10k1, intel8x0, .....
however aplay did not like this
"Can't use period equal to buffer size (%lu == %lu)")"
2009/9/9 Takashi Iwai tiwai@suse.de
At Wed, 9 Sep 2009 16:27:17 +0200, Lennart Poettering wrote:
On Wed, 09.09.09 16:14, Takashi Iwai (tiwai@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 _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel