[pulseaudio-discuss] playback from loopback over network fades, dies every few minutes and then comes back

[Nick]

On 06/15/2015 09:53 AM, Georg Chini wrote:
> On 15.06.2015 05:54, Nick wrote:
>> On 06/14/2015 12:03 PM, Georg Chini wrote:
>>> On 14.06.2015 18:54, Nick wrote:
>>>> Greetings PulseAudio folks:
>>>>
>>>> I'm trying to pipe audio between an amateur radio (basically a USB
>>>> sound
>>>> card) hooked to a Raspberry Pi and my laptop over a local network.
>>>> I've
>>>> built PulseAudio 6 on a Raspberry Pi B+ and set up module-tunnel-sink
>>>> and module-tunnel-source, and that's all functioning. I can record
>>>> audio
>>>> on my laptop and it seems to work well. However, I need to be able to
>>>> monitor the sounds coming out of the radio live, so I set up a
>>>> module-loopback with the source set to the USB sound card on the RPi.
>>>>
>>>> Here are the relevant bits in my system.pa config file:
>>>>
>>>> load-module module-tunnel-sink server=laptop sink_name=xps rate=11025
>>>> load-module module-tunnel-source server=laptop source_name=xpss
>>>> rate=11025
>>>> load-module module-loopback
>>>> source=TI_USB_Audio_CODEC-00-CODEC.analog-stereo latency_msec=100
>>>> rate=11025
>>>>
>>>> I've downsampled because I'm trying to minimize bandwidth and don't
>>>> need
>>>> hi-fi audio (after all, it's a ham radio). This works, but only for a
>>>> few minutes. Then, the audio from the loopback becomes choppy and
>>>> eventually fades out completely. It sits silently for about a minute
>>>> (sometimes more) and then comes back in full quality. A minute or so
>>>> later, the process repeats.
>>>>
>>>> Some interesting tidbits:
>>>> 1) Only the loopback fades. If I'm recording in an application on the
>>>> laptop from the networked tunnel source directly, it holds the signal
>>>> nicely the whole time (even during the fadeouts).
>>>> 2) If I connect to my local network over a VPN, the loopback fading
>>>> does
>>>> not occur at all.
>>>> 3) The fading happens both on wifi connections and on hard-wired ones.
>>>> 4) If I change the target of the loopback in pavucontrol's Playback
>>>> tab
>>>> to something else and then back to my laptop speakers, it often
>>>> stops a
>>>> fadeout and comes back strong for a minute or so (and then fades out
>>>> again).
>>>> 5) The fading occurs both with the downsampled rate set on the
>>>> loopback
>>>> and with the default.
>>>> 6) This happens on multiple remix methods, including the default and
>>>> trivial.
>>>> 7) This happens on both the Raspberry Pi B+ and on the Raspberry Pi 2.
>>>> CPU on the RPi2 is at about 20%.
>>>> 8) The client (my laptop) has PulseAudio 4.0, not 6.0 like the server.
>>>>
>>>> I've uploaded a recording of the fading phenomenon that you can listen
>>>> to here: http://partofthething.com/upload/pulseaudio-fadeout.mp3
>>>>
>>>> I'm not sure what to do to continue debugging. Any suggestions?
>>>>
>>>> Best regards,
>>>> -Nick
>>>>
>>> Hello Nick,
>>>
>>> can you send some debug output from your pulseaudio session? It
>>> might help to identify the problem. module-loopback should provide
>>> a state update each adjust_time.
>>>
>>
>> I: [pulseaudio] module-tunnel.c: Server signalled buffer
>> overrun/underrun.
>> D: [pulseaudio] module-tunnel.c: Server reports playback started.
>> I: [pulseaudio] module-tunnel.c: Server signalled buffer
>> overrun/underrun.
>> D: [pulseaudio] module-tunnel.c: Server reports playback started.
>> I: [pulseaudio] module-tunnel.c: Server signalled buffer
>> overrun/underrun.
>> D: [pulseaudio] module-tunnel.c: Server reports playback started.
>> D: [pulseaudio] module-loopback.c: Loopback overall latency is 218.50 ms
>> + 254.51 ms + 0.40 ms = 473.41 ms
>> D: [pulseaudio] module-loopback.c: Should buffer 0 bytes, buffered at
>> minimum 808 bytes
>> D: [pulseaudio] module-loopback.c: [xps] Updated sampling rate to
>> 11045 Hz.
>>
>> Let me know if there's more info that might help. Many thanks!
>> Best,
>> -Nick
>>
>
> The lines coming from module-loopback look OK.
> It might be an issue with module-loopback changing the sample rate
> of the sink-input. Can you try and run it with adjust_time=0 to avoid
> latency adjustments?
>
> Do you get the messages from the tunnel sink also when you are
> only recording? Did you test out module-tunnel-sink-new if it makes
> a difference?
>
> Regards
>              Georg
>

Georg:

I added adjust_time=0 to the loopback config line and saw a marked
improvement. The audio was smooth with no fadeouts for a good half hour.
I switched it back to just ensure it was isolated to this and indeed the
fadeouts started after a few minutes again. Excellent.

After a very long time, however, the audio with adjust_time=0 did stop
completely with these messages:

D: [alsa-sink-USB Audio] memblock.c: Pool full
D: [alsa-sink-USB Audio] memblock.c: Pool full
D: [alsa-sink-USB Audio] memblock.c: D: [pulseaudio] memblock.c: Pool full
Pool full
D: [alsa-sink-USB Audio] memblock.c: Pool full
D: [alsa-sink-bcm2835 ALSA] memblock.c: Pool full
D: [alsa-sink-bcm2835 ALSA] memblock.c: Pool full
D: [alsa-source-USB Audio] memblock.c: Pool full
D: [pulseaudio] memblock.c: Pool full
D: [alsa-source-USB Audio] memblock.c: Pool full
I: [pulseaudio] module-stream-restore.c: Synced.
D: [alsa-sink-USB Audio] ratelimit.c: 1763 events suppressed
D: [alsa-sink-USB Audio] memblock.c: Pool full
D: [alsa-sink-USB Audio] memblock.c: Pool full
D: [alsa-sink-USB Audio] memblock.c: Pool full
D: [pulseaudio] memblock.c: Pool full
D: [alsa-sink-bcm2835 ALSA] memblock.c: Pool full

I have not yet tried the module-tunnel-sink-new but will give it a shot
to see if it gets around this.

Many thanks for the advice. If you have further suggestions considering
these new Pool full messages, I'd be interested. Otherwise I'll try your
other suggestions and get back to the list.

Best,
-Nick