On 02/22/2011 12:34 PM, Fabien C. wrote: > Well, once again it seems that from both sides, it's the other side's fault. Though I claim that the root problem lies on the ALSA side, I am not so arrogant as to refuse to fix it on the Audacious side. As I mentioned before, I added a workaround in 2.4.3 that fixes the problem.
> According to comments in ALSA's bugtracker > (https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5278), audacious: > - does "not calculate the correct buffer size" My understanding, based on much reading of the ALSA docs and discussion with the ALSA devs, it that ALSA allows applications to set whatever buffer size they like so that both low-latency applications like games and high-latency applications like music players can be accommodated. By default, Audacious tries to set a buffer size of 250 ms. Often, the driver will not allow a buffer this large, in which case Audacious will look at the actual buffer size set by the driver and adjust for it by enlarging the software buffer. This behavior was reached after much trial and error and after discussion with the ALSA devs. If Raymond believes this behavior is wrong, I would like to know why he believes that. > - does not write any data by snd_pcm_writei() or snd_pcm_commit() to the > sound > card in alsa_write_audio() Raymond obviously did not look very long at the code. alsa_write_audio(), which is called from the decoding thread, writes data to the software buffer. pump(), which runs in its own thread, then reads data from that buffer and calls snd_pcm_writei(). Raymond's claim that Audacious does not write any data is clearly ridiculous, because in that case the problem would not be CPU usage but no audio being played at all. :) I would also like to hear why the particular commit that Raymond blames is at fault. His claim in this case is ironic, given that that commit in fact *fixed* another case of high CPU usage with sound drivers that set a very small period size by default. -- John Lindgren -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org