On Tue, 08.09.09 06:49, Ng Oon-Ee (ngoonee at gmail.com) wrote: > > I am pretty sure that ALSA is broken here. We nowadays first try to > > set the number of periods, and then set the buffer size in the > > hwparams struct. If this fails we print a warning message (the ones > > you see above with all the vowels regarding > > snd_pcm_hw_params_set_periods_near() > > resp. snd_pcm_hw_params_set_buffer_size_near()), but we do not > > consider this fatal. > > > > After doing this we call snd_pcm_hw_params() to activate our > > settings -- and if this fails then we consider this a fatal problem. > > > > Now the brokeness in ALSA is that after refusing our parameters it > > still fails to configure our settings, i.e. calling the two functions > > that fail breaks the hwparams setup: if we wouldn't call them, no breakage > > happens at all. > > > > The two functions in question should either succeed or fail, but if > > they fail they should not modify hwparams in a way that it > > subsequently becomes unusable for snd_pcm_hw_params(). > > > > This issue needs to be fixed in ALSA. > > > > Lennart > > > > I will report this, then. How active are ALSA devs on their IRC? To my knowledge they do not hang out on a public IRC channels. #alsa is useless. Try the alsa-devel ML. That's your best chance. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
