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@xxxxxxx> > At Wed, 9 Sep 2009 16:27:17 +0200, > Lennart Poettering wrote: > > > > On Wed, 09.09.09 16:14, Takashi Iwai (tiwai@xxxxxxx) 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@xxxxxxxxxxxxxxxx > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
