[pulseaudio-discuss] Stuttering when sending vbr stream via tunnel sink

[Tanu Kaskinen]

On Sat, 2017-12-02 at 15:28 -0800, Joe (Yu) Zhou wrote:
> Hi,
> 
> I'm trying to stream some bluetooth audio via ethernet to another
> pulseaudio server. I'm using module-tunnel-sink-new with TCP connection. On
> the sender computer I have a bluetooth stream generating a variable bit
> rate sink-input (around 44.4KHz on average), which I then move to the
> tunnel sink with 44.1KHz sample rate. What I noticed is the audio on the
> receiver side would stutter every ~6 seconds, and it's very consistent. And
> when it stutters, I observe the following log on the sender side:
> 
> (15031.656|   0.351) I: [tunnel-sink] module-loopback.c: Could not peek
> into queue
> (15031.664|   0.007) I: [tunnel-sink] module-loopback.c: Could not peek
> into queue
> (15031.672|   0.008) I: [tunnel-sink] module-loopback.c: Could not peek
> into queue
> (15031.680|   0.007) I: [tunnel-sink] module-loopback.c: Could not peek
> into queue
> (15031.688|   0.008) I: [tunnel-sink] module-loopback.c: Could not peek
> into queue
> (15031.696|   0.007) I: [tunnel-sink] module-loopback.c: Could not peek
> into queue
> (15031.704|   0.007) I: [tunnel-sink] module-loopback.c: Could not peek
> into queue
> (15031.712|   0.007) I: [tunnel-sink] module-loopback.c: Could not peek
> into queue
> (15031.720|   0.008) D: [pulseaudio] module-loopback.c: Underrun detected,
> counter incremented to 6
> 
> And then the sample rate would change.
> 
> I tried the following:
> 
>  - Changing sampling method doesn't seem to make a difference.
>  - Tried moving the bluetooth stream to a local sink with 44.1KHz sampling
> rate, and no stutter was observed.
>  - Tried adding --realtime=yes and --high-priority=yes options on the
> sender pulseaudio server, no difference.
>  - Tried creating additional remap sinks between the bluetooth stream and
> the TCP tunnel sink, no difference.
>  - Tried moving a constant bit rate stream of 44.1KHz to the tunnel sink,
> no stuttering was observed on the receiving end.
> 
> I'm wondering, is this caused by some weird interaction between resampling
> and the tunnel sink? Any suggestions how this kind of problem can be
> debugged? Thank you!

The "could not peek into queue" messages are logged when the bluetooth
source hasn't provided enough audio. Maybe something is interfering
with bluetooth every 6 seconds? What if you unload your wifi kernel
module?

-- 
Tanu

https://www.patreon.com/tanuk