At Wed, 9 Sep 2009 16:07:35 +0200, Lennart Poettering wrote: > > On Wed, 09.09.09 14:35, 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. > 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. > And if that fails, try the other way > round, and if that fails set buffer size only? And if that fails set > nothing? Yes, this sounds reasonable. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
