On Fri, Nov 6, 2020 at 1:10 PM Matt Feifarek <[email protected]> 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
