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@xxxxxxxxx> 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@xxxxxxxxx> wrote: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
_______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
