On Fri, Nov 6, 2020 at 1:10 PM Matt Feifarek <matt.feifa...@gmail.com> wrote: > Perhaps this might help: when you set the PULSE_SERVER env variable, all the > commands you run will be run against the Rpi, basically going around the > local machine configuration. That's why you're seeing different sink > configurations when you do pactl... it's effectively the same as you logging > into the pi, and running pactl there.
Yup, that makes total sense, and more or less what I assumed. > I don't use pavucontrol, but I don't know of any reason why it can't control > a sink that is in actuality a remote/tunnel sink, and the fact that the > volumes are listed there in the second dump means I might be right. But the volumes shown are different, which I think is a clue: $ PULSE_SERVER=dietpi-music pactl list sinks # i.e. bypass local pulse, go straight to pulse server on RPI ... Volume: front-left: 5727 / 9% / -63.51 dB, front-right: 5727 / 9% / -63.51 dB $ pactl list sinks # i.e. use local pulse to talk to remote RPI pulse ... Volume: front-left: 7575 / 12%, front-right: 7575 / 12% Shouldn't those be exactly the same? FWIW, the "9%" is what my MPD client shows (which is expected, since it's talking directly to Pulse on the same host). I just played with it a little more, and actually, I am sorta getting some sound with my PC as a source. Three different cases: 1. Trying to play YouTube via Firefox - it just hangs, as though it's loading the video. But if tell Firefox to use another device (e.g. my monitor), it plays right away 2. Playing a song via vlc - I have to turn up vlc's volume control to 100% *and* whatever volume pavucontrol is seeing to 100%, then I get playback - but it has a lot of artifacts, like a regular soft clicking sound 3. Playing a song via mpz - I think this is actually gstreamer based, but if I turn its volume up, plus the pavucontrol volume, then I hear playback, but it's at double speed (or maybe faster?) and also with similar click-sound artifacts In the last two cases above, I can still use my MPD client's volume control to turn up what I'll call the "master" volume, i.e. the actual hardware volume setting of the playback device. And if I completely bypass my PC's local instance of Pulse, all three cases above work fine, as expected. On my RPI, I launch the pulseaudio daemon from the CLI, with --verbose, logging to the screen. When I change volume with the MPD client, I see logs like this: I: [pulseaudio] module-device-restore.c: Storing volume/mute for device+port sink:alsa_output.default:null. I: [pulseaudio] module-device-restore.c: Storing volume/mute for device+port sink:alsa_output.default:null. However, when I change volume from my PC using pavucontrol, it looks like this: I: [pulseaudio] module-stream-restore.c: Storing volume/mute/device for stream sink-input-by-media-role:abstract. I: [pulseaudio] module-stream-restore.c: Storing volume/mute/device for stream sink-input-by-media-role:abstract. I take this as more evidence that using my PC's local pulse daemon is more than just a "proxy" to the remote RPI Pulse daemon; the local daemon is essentially adding or doing some extra "stuff" which appears to mostly break playback. Thanks again, Matt _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss