On Fri, Nov 6, 2020 at 1:10 PM Matt Feifarek <matt.feifarek@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
