[pulseaudio-discuss] Networking and volume control

[Matt Feifarek]

Hey Matt, just a follow-up:

I fired up a VirtualBox image of Ubuntu (running on my Mac as a host) and
installed pavucontrol. I was able to manually add the zeroconf-discover
module, and my rPi popped right up. Unfortunately, it popped up TWO items,
one for IPv6.

I fired up Firefox and Youtube, and definitely didn't have good results; I
got about 10s of audio, then it started to drop out, and after about 20
seconds more, it just stopped altogether. Now, this is over wifi, on a
virtualmachine with shared network.

If you'd like me to run any more troubleshooting tests to see if I can
duplicate your problems, let me know.


On Fri, Nov 6, 2020 at 4:27 PM Matt Feifarek <matt.feifarek at gmail.com>
wrote:

> 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/20201109/c871d0c6/attachment-0001.htm>