Pulseaudio + remapped sinks: stuttering refresh if pavucontrol not running

[Soukyuu]

This... is probably the most weird sounding issue I ever reported.

I have a 7.1 Realtek ALC889 chip, which I configured to have two sinks: one for my 5.1 headset, and one for my stereo speakers following the example here. I also have another headset connected via BT.

The FFT size, bar count or refresh rate I set does not seem to matter. What I'm seeing is this:

• BT headset: smooth animation, almost no CPU impact
• any of the Realtek outputs: refresh rate drops to ~150ms, CPU spikes to ~20%

And now comes the weird part: If I start pavucontrol, the stutters on Realtek output immediately go away, so does the CPU usage. It does not matter if pavucontrol is visible or minimized, as long as it is running, the refresh rate is smooth. As soon as I close pavucontrol, the stuttering starts again.

This is on an AMD Phenom II X4 970BE/nVidia 260GTX running KDE/arch linux x64. I'm running the latest deadbeef-devel as well as latest git snapshot of musical spectrum.

Any idea what might be causing this? I think I'm seeing something like this with the original spectrum component, but it does not have a configurable refresh rate and the one it has set barely differs from the stuttering I'm seeing.

[cboxdoerfer]

Interessting bug. To me this sounds more like an audio issue. My first guess is there's something wrong with resampling, the deadbeef output plugin or pulse audio. Do you by any chance use PulseAudio as the output plugin in deadbeef? If so, try to switch to the ALSA output plugin and see if that helps.

[Soukyuu]

Indeed, I was. With alsa plugin -> default audio device (being pulseaudio server), the animation remains smooth. This is weird though, I'd expect deadbeef -> pulsaudio to behave the same as deadbeef -> alsa -> pulseaudio.

Also, not sure if I was being unclear, but the audio itself does not stutter, only the animation in the component is.

[cboxdoerfer]

Then that's most likely an issue with pulse audio or the pulse audio output plugin. The audio doesn't necessarily need to stutter, e.g. when pulse audio is doing something wrong with resampling and downsamples to 22kHz the animations would automatically look choppy. But you should be able to notice a difference in the audio quality if you listen closely, a low samplerate leads to a loss in clarity and resolution especially in the high frequency range.

[Soukyuu]

But if it was doing resampling wrong, why would it get fixed by merely starting pavucontrol (volume control app)? It doesn't have any samplerate/resampling settings. There is also no audible difference between ddb -> alsa -> pulse and ddb -> pulse, as far as I can tell.

In fact, I had a problem with ALSA using a bad resampler where the sound sounded heavily distorted for example on piano notes, so I think I'd hear a difference if it was that...

Maybe ddb's pulseaudio plugin is doing something wrong, or gets confused by the separated sinks... but then, even using the unsplit audio card for the output shows the same behavior. I should probably open a bug on the ddb tracker...

I take it you can't reproduce it on your side?

[cboxdoerfer]

Don't know why starting pavucontrol fixes that, but I'll have a look at that. Because now I was able to reproduce the bug. With my default USB-DAC it works just fine, but with my internal audio chip I get the same behaviour as you when I choose the pulse audio outplut plugin. Here there's also a clear loss in audio quality when it happens.

If you use the spectrogram plugin you can also see what's going on; the refresh rate of the visualization remains as usual, but audio samples arrive less often - which leads to a stuttering visualization in the spectrum and artifacts in the spectrogram plugin.

And yes opening a bug report on the deafbeef bugtracker is a good idea.

[Oleksiy-Yakovenko]

the refresh rate of the visualization remains as usual, but audio samples arrive less often - which leads to a stuttering visualization in the spectrum and artifacts in the spectrogram plugin.

This sounds like a glitch in the deadbeef visualization data processing, even though I don't see how that may affect the animation smoothness.

But if that's the case -- it should be fairly simple to simulate, by setting buffer size to a large value. e.g. 16 or 32K. Then the issue would appear with any output plugin. And then we can find a workaround.

[Oleksiy-Yakovenko]

I just did that, set the buffer size in alsa plugin settings to 32K, period size 8K, and got the result similar to what is described in this bug report.

[cboxdoerfer]

The animation smoothness is affected because of that: If I get the same samples from the streamer for a long time, or the wavedata listener is called less frequently, the spectrum is generated from the same samples a couple times in a row and looks the same until the audio samples get updated.

[Soukyuu]

I'm a bit confused... is this fixed, or was this closed because it's not a bug in the plugin but deadbeef?

[Oleksiy-Yakovenko]

It is both:

• not fixed
• it's a bug in deadbeef (referenced above)

[Soukyuu]

Ok, thanks for clearing it up.