I posted recently about this under the subject "Networking and volume control", but thought I'd start a new thread, as my focus is now less about volume, and more about getting reliable playback on a tunnel. Here's the setup: I have PulseAudio running on a Raspberry Pi, intended to be a music server for my office workstation/PC. The problem I'm having is: everything seems to work fine, as expected, when I direct connect from my PC to the RPI using PULSE_SERVER. However, on my workstation, I regularly need to switch between the RPI server and local sound devices, so direct connect is not appropriate for my use case. But I'm having issues with reliable playback when using a tunnel. If I play a wav file using paplay prefixed with PULSE_SERVER (i.e. direct connection), then things seem to work as expected: $ PULSE_SERVER=dietpi-music paplay --verbose song.wav Opening a playback stream with sample specification 's16le 2ch 44100Hz' and channel map 'front-left,front-right'. Connection established. Stream successfully created. Buffer metrics: maxlength=4194304, tlength=352800, prebuf=349276, minreq=3528 Using sample spec 's16le 2ch 44100Hz', channel map 'front-left,front-right'. Connected to device alsa_output.default (index: 0, suspended: no). Stream started. Time: 1.126 sec; Latency: 2005612 usec. The last line is interesting: here the "Time" counter keeps going up, and the latency changes constantly, but stays approximately the same. Now if I play the same file without the PULSE_SERVER prefix, i.e. by using a tunnel, then things look like this: $ paplay --verbose song.wav Opening a playback stream with sample specification 's16le 2ch 44100Hz' and channel map 'front-left,front-right'. Connection established. Stream successfully created. Buffer metrics: maxlength=4194304, tlength=352800, prebuf=349276, minreq=3528 Using sample spec 's16le 2ch 44100Hz', channel map 'front-left,front-right'. Connected to device tunnel.dietpi-music.local.alsa_output.default (index: 19, suspended: no). Stream started. Time: 0.000 sec; Latency: 108373832 usec. I do get playback. But in this case, that Time counter is stuck at 0.000 seconds (it never increments). Furthermore, the Latency counter keeps going up (strictly increasing). The final number when the song playback finishes is approximately the same as the length of the song (309346656 usec). The other things I've observed: playback of a YouTube video in Firefox, which uses PulseAudio. It works completely fine when direct-connected. But when using the tunnel, sometimes playback completely hangs (like a network timeout); sometimes the video will play, but after a random amount of time, it will stop, or reset itself back to the beginning. I have this program "Transcribe!", which is gstreamer based. One feature this program has is a live waveform of the left and right channels, which updates in real-time as the song plays back. When I use this program with PULSE_SERVER (i.e. direct-connect to the RPI) it works as expected. But when using the tunnel, I do get playback, but that waveform is static, not updating in realtime as it's supposed to. All these things together make me think that the tunnel appears to be a "one way" construct. It looks like I can send data to the tunnel (and get playback), but it seems like no data comes back. I assume the PulseAudio protocol is two-way, obviously you need to send audio data to the server, but presumably the server needs to send back acknowledgements and other status information. Thanks! Matt _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
