[pulseaudio-discuss] Networking and volume control

Fri Nov 6 22:27:11 UTC 2020

I think your theory is right; a tunnel sink isn't just a network proxy...
but I'd have to read up as to why. It might make sense that the volumes are
different in that regard... given the design notion of the tunnel, it might
make sense that you don't want to mess with the volume of the remote sink
necessarily, though I see that you do for your use case. I think maybe
partly stuff is quiet because first you're taking a signal to 12% of its
full strength, then playing THAT back at 9% of its strength... which is a
VERY low level signal (1.08%), especially given that we hear in decibels
rather than %.

I've had some software glitch like you describe... one thing to look at is
if you're preventing PA from resampling or from adjusting sample rates as
necessary. I know you might not like the notion of messing with your bits,
but if you're doing digital volume, you are anyway. That might be why
things are stuttering and playing the wrong speed; maybe your PC is doing
48K and the Pi is 44, or such. The resamplers available to PA are extremely
high quality, especially the "sox-vhq" or whatever it's called. I bet the
clicks and pops are the two daemons trying to figure out how to recover
from different sample rates, or buffers and so on.

My experience is that I over-thought things; best to start with default
settings (including auto-detecting hardware and such) and get your use case
working... THEN, if you're worried about quality or are experiencing lag or
something, start tweaking stuff.

I also found that DietPI's PA and Alsa stuff was flakier than stock
Raspbian... but I thought that was limited to my hardware (which was an
Allo board rather than an actual RPi). With an actual Pi4 and PA, it's been
rock solid... with an actual ethernet hard-line, which helps, too, I bet.

One common problem I had was that some apps are actually not looking to
talk to Pulseaudio; they are going to alsa, and alsa is punting it back to
PA. That's a sort of "fail safe" that some distros seem to put for some
software that isn't compiled against PA, and I see that advice in various
forums and things on the net. Perhaps double-check that VLC and Firefox are
actually talking to Pulseaudio directly rather than indirectly via ALSA?
(I'm not using Linux desktop right now, so I can't look for myself, sorry)

If you want a direct connection, without the "non-proxy" stuff you're
mentioning, then yes, you need to tell the apps not to talk to the local
system but to talk to the remote system. I think this is accomplished by
the environment variable.

Have you tried with just low-level tools like "paplay"?

If I were you, and I wanted to get working what you're talking about
(assuming I'm right: you have a Pi connected to speakers somewhere, and you
want to listen to MPD there, but ALSO sometimes send streams to it from
your desktop, but not always) I would do this:

1. Revert the Pi's Pulseaudio settings to complete stock -- or the minimum
changes necessary to get it running without a logged in user with hardware
volume, etc)
1a. Make sure that there is only one sink in the Pi's PA configuration (not
the onboard sound, or HDMI or whatever... perhaps by setting the card
profile(s) to off)
2. Verify that you can make sound with paplay on the pi.
3. Get MPD running on the Pi, make sure you can make sound and control the
volume as you like.
4. on the Pi, open a shell with the right user/credentials and do
'pactl load-module module-zeroconf-publish'

Then, on your PC,
1. also revert PA to as close to stock as possible; this might be in your
homedir under .pulse...
2. open a shell and do 'pactl load-module module-zeroconf-discover'
3. check for the sinks...
4. use paplay to play a wav file to the right sink; listen for proper speed
and no glitches...

If this is all working, now you have a good place to build from. I don't
remember the name of the PA GUI stuff, but there is for sure a program to
switch streams among sinks (not stock in Debian/Ubuntu, I had to add it,
but I think it's the one that contains pavucontrol). Or maybe that IS
pavucontrol?

For controlling the volume, I'd make a shim like I mentioned that controls
the REMOTE SINK rather than the tunnel sink. This would be a separate icon
on your desktop (or whatever) that only controls the remote sink volume.
And don't mess with the local tunnel sink's volume... does that make sense?

If this all works, you can consider removing the zeroconf stuff, and just
using the PA settings to allow tcp connections, and loading the remote sink
by the "tunnel sink" module, but I don't think this has any benefits over
zeroconf.

I hope this helps. Sorry this has been so hard; I've been there!

On Fri, Nov 6, 2020 at 3:54 PM Matt Garman <matthew.garman at gmail.com> wrote:

> On Fri, Nov 6, 2020 at 1:10 PM Matt Feifarek <matt.feifarek at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20201106/3f3e9eb0/attachment.htm>