Wow! Good find!
I'll see if I can duplicate this result by installed some kind of time sync in the virtualbox machine that I mentioned.
As far as controlling the volume remotely, I think you're right in thinking that the tunnel isn't a remote control onto the remote sink, it's a "virtual" sort of sink that passes through to the real one.
I'd look up how to load env variables into a .desktop file and make a launch icon for pavucontrol and call it something like "RPi Pavucontrol". Pavucontrol seems to have some more features than I recall seeing, so maybe one can simply select the remote sink and mess with it? (either of these approaches will require that you have permissions to do that on the remote server)
In my own quick experiment, I was able to use pasystray to select what server to mess with, then run pavucontrol, etc... but it gets confusing fast.
On Mon, Nov 9, 2020 at 1:13 PM Matt Garman <matthew.garman@xxxxxxxxx> wrote:
At the risk of jinxing myself, I think I figured this out. I enabled
time sync (using systemd-timesyncd) on both client PC and server RPI.
This github post[1] gave me the idea to check on time sync.
There is a hint about this in the Arch Wiki[2]: "Ensure that client
and server systems agree on the time (i.e., use NTP), or audio streams
may be choppy or may not work at all". I have actually read that
several times, but mistakenly thought all my systems were already
doing time sync. It turns out, my Raspberry Pi server (running
DietPi) was only syncing at boot and once per day. It looks like my
workstation wasn't doing any kind of sync! I actually have an NTP
server running in my home. So I set both systems to continuously sync
to my own time server. So far so good. Testing all my typical
use-cases, things mostly seem to work the same between
direct-connecting and using a tunnel. I say "mostly" because I still
can't control the master (hardware) volume on the RPI via the tunnel.
Maybe I'm overlooking it, but I don't see anywhere in the PulseAudio
documentation about tight time sync being necessary for the tunnel
sink to work reliably. I looked at this[3] and this[4].
I'm also curious to what degree of precision time sync is needed. I'm
certain neither of my systems were significantly out of sync; they
were certainly close enough from a "human" perspective.
[1] https://github.com/mpv-player/mpv/issues/959
[2] https://wiki.archlinux.org/index.php/PulseAudio/Examples#PulseAudio_over_network
[3] https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Network/
[4] https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#module-tunnel-sinksource
Thanks again!
Matt
On Sun, Nov 8, 2020 at 8:07 PM Matt Garman <matthew.garman@xxxxxxxxx> wrote:
>
> 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
_______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
