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 <[email protected]> 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 <[email protected]> > wrote: > >> 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 >> >
_______________________________________________ pulseaudio-discuss mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
