[Pkg-audacious-maintainers] Bug#613203: audacious: High CPU usage with snd_hda_intel based soundcard

[John Lindgren]

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