Re: [pulseaudio-discuss] Latency/lag with tcp tunnel
Reviving this two-month-old thread for a little FYI follow-up. Quick recap: I was experiencing noticeable lag/latency between my pulse client PC and my pulse server Raspberry Pi. Turns out most of it was due to the Allo Kali device I was using between the RPI and audio device. However... On Wed, Jan 27, 2021 at 2:23 AM Sean Greenslade wrote: > So this is where the limitations of module-tunnel come in. The original > tunnel has the latency modification code commented out, so you're stuck > at the default sink latency setting of 250 ms. > > One thing you can try is using module-tunnel-sink-new instead of > module-tunnel-sink, as it seems to have dynamic latency calculations > in its code (though I'm not familiar enough with the PA internals to > know how that code actually works). ...while removing the Allo Kali device got me well into "good enough" territory, I remained curious about tunnel-sink-new. Finally got around to giving it a try. For review, this is what I typically saw for latency on the old/original tunnel sink module: Latency: 137764 usec, configured 25 usec The new module clearly has some dynamic calculations going on. I hacked up a little script to periodically run "pactl list sinks" and grep the latency info for the module-tunnel-sink-new. What's interesting to me is that the "configured" latency seems to fall into one of three buckets: 11, 75, or 200 ms. Here are a few samples from my "latency logger": Latency: 184712 usec, configured 20 usec Latency: 203054 usec, configured 20 usec Latency: 64141 usec, configured 75000 usec Latency: 84139 usec, configured 75000 usec Latency: 19927 usec, configured 11610 usec Latency: 25305 usec, configured 11610 usec There are actually a lot of "Latency: 0 usec, configured 0 usec" records, which correspond to when there is no playback (i.e. idle sink). What I find interesting is that it seems like the configured latency value corresponds to the application that causes the sink to transition from idle to active. In particular, playing Minecraft almost always results in the 11.6ms configured latency. Spotify always results in the 200ms configured latency. And it seems "everything else" triggers the 75ms latency. What's also interesting is that when the new tunnel module falls into the 200ms bucket, the reported latency of 180--200ms is higher than when using the old module, which was generally around 140ms, despite the configured 250ms latency. At any rate, I'm happy with the state of things currently, just thought I'd post some data that others might find interesting. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Latency/lag with tcp tunnel
Hi Matt and Sean, thank you so much for your help! I was planning to try removing the Kali, but Sean's email pushed me to try it sooner than later. I did just that last night, and now the lag is all but gone. Using paplay directly on the RPI results in *immediate* playback, as soon as I hit enter (before there was a very noticeable delay). VIdeos are once again watchable (using my PC for the monitor and as a pulseaudio client to the RPI server). There's still a very tiny latency that is perceptible in some cases - but this is the same as what I experienced with the RPI 4 and different DAC/amp combo. This I can live with, though I might try to further tweak a bit to see if it can be completely eliminated. A few somewhat off-topic comments below... On Thu, Jan 28, 2021 at 6:39 PM Sean Greenslade wrote: > Wow, that was kind of a long tangent. Long story short, I would take > that reclocker out of the picture and try feeding your I2S signals > directly to the DAC. Use short connections, shielded if possible, since > I2S is not really meant to be used as a board-to-board protocol. > > This may actually help your latency issues, since the Allo claims to > have a 0.7 second (!) buffer. I do appreciate your analysis, that was an interesting read. In an earlier email, I said I've been using the Kali for years and never noticed this latency. But I realized in the past, I only used it for music playback. IOW, previously, I never used it in a situation where the lag would actually be an issue. So it's likely been there before, I just never noticed it. Your comments about the RPI's I2S jitter are nearly earth-shattering to me. Years ago, I read that dimdim article you linked. I do not have the knowledge to identify the test setup/methodology as questionable, and have since lived with the simple notion that "RPI I2S == bad", and absolutely requires reclocking. I think it is true that, for 44.1khz sample rates (and its multiples), indeed the RPI cannot exactly generate that clock, as it's master clock is not an integer multiple of that (looks like 19.2 MHz for RPI3 and earlier, 54.0 MHz for RPI4). However, whether or not that makes a difference is dependent on the downstream component's ability to adapt. I also have an Amanero, which is a USB to I2S device. I might try playing with it to see if it adds latency, just for kicks. At least I'm not buying $1000 power cables. ;) If you guys (or anyone else) are interested in my ma12070p project, feel free to chat with me off-list. See also this diyAudio thread: https://www.diyaudio.com/forums/class-d/347422-infineon-ma12070-class.html. My first post about my project is on page 30, #296. Thanks again, much appreciated! ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Latency/lag with tcp tunnel
On Mon, Jan 25, 2021 at 10:58 PM Sean Greenslade wrote: > As a data point, I routinely use networked TCP streams with pulse, and > on wired ethernet links I tend to see only ~50 ms of delay. > > One avenue to investigate is to see what pulseaudio thinks the latency > is. If you run the command "pactl list sink_inputs" on the device with > the sound card, you'll get something like this: > > [sean@bailey ~]$ pactl list sink-inputs > Sink Input #2 > Driver: protocol-native.c > Owner Module: 9 > Client: 17 > Sink: 3 > Sample Specification: float32le 2ch 48000Hz > Channel Map: front-left,front-right > Format: pcm, format.sample_format = "\"float32le\"" format.rate = > "48000" format.channels = "2" format.channel_map = > "\"front-left,front-right\"" > Corked: no > Mute: no > Volume: front-left: 60293 / 92% / -2.17 dB, front-right: 60293 / > 92% / -2.17 dB > balance 0.00 > Buffer Latency: 226791 usec > Sink Latency: 16780 usec > Resample method: speex-float-1 > > Note the reported "Sink Latency" of ~16 ms (in my setup, I saw it vary > from 4 ms to 25 ms). What does your setup report? And what is the > reported latency of your audio device itself (pactl list sinks). Thank you for the suggestion. Here are the two sink-inputs on the RPI server. They are the tcp and unix domain sockets, respectively. In both cases, the sink latency is around 10ms, which is roughly the same as you. That's the "Sink Latency", is the "Buffer Latency" important? root@dietpi-ma12070p:~# pactl list sink-inputs Sink Input #0 Driver: protocol-native.c Owner Module: 7 Client: 1 Sink: 0 Sample Specification: s32le 2ch 44100Hz Channel Map: front-left,front-right Format: pcm, format.sample_format = "\"s32le\"" format.rate = "44100" format.channels = "2" format.channel_map = "\"front-left,front-right\"" Corked: yes Mute: no Volume: front-left: 65536 / 100% / 0.00 dB, front-right: 65536 / 100% / 0.00 dB balance 0.00 Buffer Latency: 139841 usec Sink Latency: 9718 usec Resample method: n/a Properties: media.name = "Built-in Audio for matt@sewage" media.role = "abstract" application.name = "pulseaudio" native-protocol.peer = "TCP/IP client from 10.18.51.34:46968" native-protocol.version = "34" application.id = "org.PulseAudio.PulseAudio" application.version = "14.0" application.process.id = "947578" application.process.user = "matt" application.process.host = "sewage" application.process.binary = "pulseaudio" application.language = "en_US.UTF-8" window.x11.display = ":0" application.process.machine_id = "31d757b445f140b1b50278a35a34a1e5" application.process.session_id = "2" module-stream-restore.id = "sink-input-by-media-role:abstract" Sink Input #2 Driver: protocol-native.c Owner Module: 6 Client: 5 Sink: 0 Sample Specification: s16le 2ch 44100Hz Channel Map: front-left,front-right Format: pcm, format.sample_format = "\"s16le\"" format.rate = "44100" format.channels = "2" format.channel_map = "\"front-left,front-right\"" Corked: no Mute: no Volume: front-left: 65536 / 100% / 0.00 dB, front-right: 65536 / 100% / 0.00 dB balance 0.00 Buffer Latency: 446349 usec Sink Latency: 9846 usec Resample method: copy Properties: media.name = "ALSA Playback" application.name = "ALSA plug-in [mpd]" native-protocol.peer = "UNIX socket client" native-protocol.version = "32" application.process.id = "504" application.process.user = "mpd" application.process.host = "dietpi-ma12070p" application.process.binary = "mpd" application.language = "C" application.process.machine_id = "1000380a73144486937defb00927c831" module-stream-restore.id = "sink-input-by-application-name:ALSA plug-in [mpd]" Here's the sink latency, also looks reasonable to my untrained eyes: root@dietpi-ma12070p:~# pactl list sinks Sink #0 State: RUNNING Name: alsa_output.default Description: Built-in Audio Driver: module-alsa-sink.c Sample Specification: s32le 2ch 44100Hz Channel Map: front-left,front-right Owner Module: 5 Mute: no Volume: front-left: 8308 / 13% / -53.82 dB, front-right: 8308 / 13% / -53.82 dB balance 0.00 Base Volume: 65536 / 100% / 0.00 dB Monitor Source: alsa_output.default.monitor Latency: 9833 usec, configured
Re: [pulseaudio-discuss] Latency/lag with tcp tunnel
On Mon, Jan 25, 2021 at 9:27 PM Matt Feifarek wrote: > My guess is that it's likely in the amp; did you try hooking up the Topping > to the new pi? Or, the converse; hook the amp up to the workstation and see > if you see a delay? I have a bad feeling that might indeed be the problem, but wanted to eliminate any possible problem with my software config first. Swapping the RPI 3 and 4 is indeed a perfectly valid suggestion. Admittedly, I haven't done that because it's a lot of hardware reworking, was hoping to deduce the program with only config changes and such (ok, ok, I'm lazy!). > Does the Pi have a USB soundcard, or a "hat" sort of thing? Some of the hats > have buffers in them to reclock the audio signal; this can add a delay too. > I'm not familiar with the MA12070P, but as it's I2S, maybe it is adding a > buffer. The ma12070p is a newish digital input (I2S) class D amplifier (essentially, a "power DAC" or a DAC and amplifier in one chip). Between the RPI and amp is an Allo Kali I2S reclocker. I don't think the Kali adds any meaningful latency, as I've used it extensively with other I2S DACs, and never before noticed lag. I do know that the various controls of the ma12070p (volume, I2S format, etc etc) are done via the I2C serial bus, which I don't believe is a high-speed/low-latency bus. > You can login to the pi over ssh and turn up logging to a very verbose degree > and watch it, you'll see messages about measured latency, probably both on > the "server" (the Pi) and on the client (your workstation). Good idea, I will do that and report back. > Regarding your last question, you could certainly login to the Pi, put a wav > file over there, and do "paplay file.wav" and see if the delay after hitting > enter "feels" the same as over the network. My guess is that it will. I did that both directly on the RPI server, and the workstation client as well. It does seem like there is a lag doing paplay directly on the server. The lag might be slightly greater on the client, but I wouldn't swear to it. (It's one of those things that's so simple and trivial, yet when I do it multiple times in a row, I start second-guessing myself, kind of like when you say the same word over and over again, it starts to sound foreign after enough repetitions.) > If the delay can't be worked around, there might be ways to tell the pulse > audio stack to account for it in playback to get for example your YouTube to > sync up right. I know that VLC can do this. It might come to that. I'll continue to investigate, see if I can conclusively determine if that's the fundamental issue. Thanks! ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Latency/lag with tcp tunnel
I am using a Raspberry Pi as a "sound server". Essentially, the RPI is connected to the actual audio hardware. The RPI advertises itself via module-native-protocol-tcp and module-zeroconf-publish. My desktop/workstation in turn uses the RPI for playback via module-tunnel. Everything seems to work as expected, except there is a noticeable lag between doing something on the PC, and having the audio "catch up" on the RPI. For example, watching YouTube - the audio and video are out of sync to the point of being unwatchable. Or using a simple audio player on the PC, hitting "play" or "stop", there is a noticeable delay from when the button is pressed to when the action actually takes effect. I can't think of a good way to measure the lag, but I'm guessing it's around half to three fourths of a second. To be clear, there are no stutters or skips or other audio artifacts. Playback is smooth and sounds as good as I expect - but the lag is a problem. What's interesting is, this is actually the second RPI sound server I've built. The first one had this lag, but to a much smaller degree, as in, barely noticeable. The differences between the systems are: the first (barely noticeably lag) is an RPI 4, connected to a Topping D70 DAC. The new system (with the obvious latency issue) is an RPI 3, connected to an MA12070P-based amplifier. IOW, the RPI hardware and audio hardware are different. But the network is the same, and the devices are all in the same physical location (i.e. same cable length). The RPI 3 does have only 100mbps network, and the RPI 4 has gigabit. The rest of the network chain is all gigabit. These are all hardwired networks (i.e. no wireless). I feel like 100mbps is more than sufficient for CD-quality audio. The RPI isn't running any other services or doing any other work. Any thoughts on how I might track this down? Or what config options I can play with to see if it improves the situation? Also, as the RPI is headless, I can't think of a good way to determine if the latency is on the RPI itself, or comes from the network between the PC and RPI. Thanks! ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How manage volume remotely on pulseaudio
On Wed, Jan 20, 2021 at 7:24 AM Christian Schmitz wrote: > Yes I install the pavucontrol on the kid computer. Inside SSH session > if i > open Chromium it open en kid screen, but if i open pavucontrol then open in > my screen and cant connect with kid pulseaudio. Have you looked into this: https://github.com/Siot/PaWebControl I haven't used it, just ran across it. But, if it works as advertised, you should be able to run it on your kid's computer, then use a web GUI to change the volume. It appears to be just a wrapper around pactl, so you could also skim the source for inspiration on how to create your own little scripts/macros using pactl directly. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How manage volume remotely on pulseaudio
To be clear, you want pavucontrol installed on your kid's machine, and you will run it directly from her machine. (In theory, you can run pavucontrol on your machine, but control volumes on your kid's machine. But I expect that to be even more complicated.) So, the first step is to make sure X forwarding is working as expected. Ssh into your kid's machine, then try to run a familiar graphical program. I always use "xlogo" for this, it's about the simplest X11 program possible. But, in my experience, many modern Linux distributions do not install this by default. If xlogo is not installed, and you can't figure out how to get it installed, try running something you know works, like an xterm (or gnome-terminal, Konsole, rxvt, etc), or even a browser. This is just a sanity check that you can run graphical X11 programs on your kid's computer, but have them display on yours. As I wrote that, I thought of something: do you know, does your distribution use Wayland instead of X11? If so, that complicates things, as I am not familiar with getting Wayland to do remote display the way X11 does. Let us know how it goes! On Tue, Jan 19, 2021 at 3:04 PM Christian Schmitz wrote: > > Dear Matt: > Thanks for the patience. I install pavucontrol and do > "ssh -Y user@kid" > I get an error, you can see in the image. > if i run pavucontrol in the same machine of my kid goes to bacground and none > is open. > > Best Regards > Christian > > > > On Tuesday 19 January 2021 16:58:32 Matt Garman wrote: > > Ssh with X forwarding: "ssh -Y user@kid". The "-Y" is what does the X > > forwarding. Hopefully, with that you can run "pavucontrol", which is > > a GUI that is loosely similar to alsamixer. > > > > On Tue, Jan 19, 2021 at 1:52 PM Christian Schmitz > wrote: > > > Dear Matt > > > I have full access to the machine, ( i install it for my wife and > > > kid). Sadly i dont know how do ssh with X forwarding. So i go for pactl. > > > > > > user@kid > pactl > > > no valid comand > > > user@kid > pactl > > > Big big list of things. > > > > > > i get some of sucess doing: > > > pactl set-sink-volume 0 32768 > > > > > > There are some tool more friendly that pactl, with look similar to > > > alsamixer or etc? > > > > > > Best Regards > > > Christian > > > > > > On Tuesday 19 January 2021 15:53:03 Matt Garman wrote: > > > > If you can login as your child (i.e., same user account as him) on his > > > > Linux system (ssh with X forwarding), then you should be able to run > > > > "pavucontrol". Loosely speaking, pavucontrol is to Pulse Audio as > > > > alsamixer is to ALSA. It's a GUI app. I'm not sure if there exists a > > > > strictly text equivalent of pavucontrol. > > > > > > > > There is also a commandline tool call "pactl". This would allow you > > > > to control the Pulse Audio daemon on your child's computer without a > > > > GUI (though there is a bit of a learning curve). > > > > > > > > On Tue, Jan 19, 2021 at 12:13 PM Christian Schmitz > > > > > > wrote: > > > > > Hi everyone: > > > > > > > > > > I am in the office with my computer ( Linux tumbleweed), and my kid > > > > > of 3 years old is in another computer showing videos from youtube. > > > > > Both computer have a normal user sound configuration ( each computer > > > > > playing their own sound). > > > > > > > > > > Some videos are quieter and another are very loudness. With my first > > > > > kid (10 years back) i do: > > > > > 1)SSH as root > > > > > 2)amixer and upper or lower the volume. > > > > > > > > > > Now i cant find a way to do this with pulseaudio. If i do > > > > > 1)I do ssh as root successfully > > > > > 2) > > > > > 2.1) # amixer > > > > > ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: > > > > > Connection refused > > > > > > > > > > 2.2) # alsamixer > > > > > ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: > > > > > Conexión negada (Connection refused in spanish) > > > > > > > > > > > > > > > 2.3) if i do sudo to the same linux user that is showing the video: > > > > > > > > > > user@computer> amixer > > &
Re: [pulseaudio-discuss] How manage volume remotely on pulseaudio
Ssh with X forwarding: "ssh -Y user@kid". The "-Y" is what does the X forwarding. Hopefully, with that you can run "pavucontrol", which is a GUI that is loosely similar to alsamixer. On Tue, Jan 19, 2021 at 1:52 PM Christian Schmitz wrote: > > Dear Matt > I have full access to the machine, ( i install it for my wife and > kid). Sadly > i dont know how do ssh with X forwarding. So i go for pactl. > > user@kid > pactl > no valid comand > user@kid > pactl > Big big list of things. > > i get some of sucess doing: > pactl set-sink-volume 0 32768 > > There are some tool more friendly that pactl, with look similar to alsamixer > or etc? > > Best Regards > Christian > > On Tuesday 19 January 2021 15:53:03 Matt Garman wrote: > > If you can login as your child (i.e., same user account as him) on his > > Linux system (ssh with X forwarding), then you should be able to run > > "pavucontrol". Loosely speaking, pavucontrol is to Pulse Audio as > > alsamixer is to ALSA. It's a GUI app. I'm not sure if there exists a > > strictly text equivalent of pavucontrol. > > > > There is also a commandline tool call "pactl". This would allow you > > to control the Pulse Audio daemon on your child's computer without a > > GUI (though there is a bit of a learning curve). > > > > On Tue, Jan 19, 2021 at 12:13 PM Christian Schmitz > wrote: > > > Hi everyone: > > > > > > I am in the office with my computer ( Linux tumbleweed), and my kid of 3 > > > years old is in another computer showing videos from youtube. Both > > > computer have a normal user sound configuration ( each computer playing > > > their own sound). > > > > > > Some videos are quieter and another are very loudness. With my first kid > > > (10 years back) i do: > > > 1)SSH as root > > > 2)amixer and upper or lower the volume. > > > > > > Now i cant find a way to do this with pulseaudio. If i do > > > 1)I do ssh as root successfully > > > 2) > > > 2.1) # amixer > > > ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: > > > Connection refused > > > > > > 2.2) # alsamixer > > > ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: > > > Conexión negada (Connection refused in spanish) > > > > > > > > > 2.3) if i do sudo to the same linux user that is showing the video: > > > > > > user@computer> amixer > > > XDG_RUNTIME_DIR (/run/user/0) is not owned by us (uid 1001), but by uid > > > 0! (This could e.g. happen if you try to connect to a non-root PulseAudio > > > as a root user, over the native protocol. Don't do that.) > > > ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: > > > Connection refused > > > > > > How i can control the sound volume of my kid from my computer? > > > > > > Thanks all > > > Christian Schmitz > > > > > > -- > > > Be Free, Be Linux > > > ___ > > > pulseaudio-discuss mailing list > > > pulseaudio-discuss@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > > > > ___ > > pulseaudio-discuss mailing list > > pulseaudio-discuss@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > > > -- > Be Free, Be Linux > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How manage volume remotely on pulseaudio
If you can login as your child (i.e., same user account as him) on his Linux system (ssh with X forwarding), then you should be able to run "pavucontrol". Loosely speaking, pavucontrol is to Pulse Audio as alsamixer is to ALSA. It's a GUI app. I'm not sure if there exists a strictly text equivalent of pavucontrol. There is also a commandline tool call "pactl". This would allow you to control the Pulse Audio daemon on your child's computer without a GUI (though there is a bit of a learning curve). On Tue, Jan 19, 2021 at 12:13 PM Christian Schmitz wrote: > > Hi everyone: > > I am in the office with my computer ( Linux tumbleweed), and my kid of 3 years > old is in another computer showing videos from youtube. Both computer have a > normal user sound configuration ( each computer playing their own sound). > > Some videos are quieter and another are very loudness. With my first kid (10 > years back) i do: > 1)SSH as root > 2)amixer and upper or lower the volume. > > Now i cant find a way to do this with pulseaudio. If i do > 1)I do ssh as root successfully > 2) > 2.1) # amixer > ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection > refused > > 2.2) # alsamixer > ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Conexión > negada (Connection refused in spanish) > > > 2.3) if i do sudo to the same linux user that is showing the video: > > user@computer> amixer > XDG_RUNTIME_DIR (/run/user/0) is not owned by us (uid 1001), but by uid 0! > (This could e.g. happen if you try to connect to a non-root PulseAudio as a > root user, over the native protocol. Don't do that.) > ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection > refused > > How i can control the sound volume of my kid from my computer? > > Thanks all > Christian Schmitz > > -- > Be Free, Be Linux > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Tunnel vs direct connect to remote PA server - tunnel unreliable
At the risk of jinxing myself, I think I figured this out. I enabled time sync (using systemd-timesyncd) on both client PC and server RPI. This github post[1] gave me the idea to check on time sync. There is a hint about this in the Arch Wiki[2]: "Ensure that client and server systems agree on the time (i.e., use NTP), or audio streams may be choppy or may not work at all". I have actually read that several times, but mistakenly thought all my systems were already doing time sync. It turns out, my Raspberry Pi server (running DietPi) was only syncing at boot and once per day. It looks like my workstation wasn't doing any kind of sync! I actually have an NTP server running in my home. So I set both systems to continuously sync to my own time server. So far so good. Testing all my typical use-cases, things mostly seem to work the same between direct-connecting and using a tunnel. I say "mostly" because I still can't control the master (hardware) volume on the RPI via the tunnel. Maybe I'm overlooking it, but I don't see anywhere in the PulseAudio documentation about tight time sync being necessary for the tunnel sink to work reliably. I looked at this[3] and this[4]. I'm also curious to what degree of precision time sync is needed. I'm certain neither of my systems were significantly out of sync; they were certainly close enough from a "human" perspective. [1] https://github.com/mpv-player/mpv/issues/959 [2] https://wiki.archlinux.org/index.php/PulseAudio/Examples#PulseAudio_over_network [3] https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Network/ [4] https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#module-tunnel-sinksource Thanks again! Matt On Sun, Nov 8, 2020 at 8:07 PM Matt Garman wrote: > > I posted recently about this under the subject "Networking and volume > control", but thought I'd start a new thread, as my focus is now less > about volume, and more about getting reliable playback on a tunnel. > > Here's the setup: I have PulseAudio running on a Raspberry Pi, > intended to be a music server for my office workstation/PC. > > The problem I'm having is: everything seems to work fine, as expected, > when I direct connect from my PC to the RPI using PULSE_SERVER. > However, on my workstation, I regularly need to switch between the RPI > server and local sound devices, so direct connect is not appropriate > for my use case. But I'm having issues with reliable playback when > using a tunnel. > > If I play a wav file using paplay prefixed with PULSE_SERVER (i.e. > direct connection), then things seem to work as expected: > > $ PULSE_SERVER=dietpi-music paplay --verbose song.wav > Opening a playback stream with sample specification 's16le 2ch > 44100Hz' and channel map 'front-left,front-right'. > Connection established. > Stream successfully created. > Buffer metrics: maxlength=4194304, tlength=352800, prebuf=349276, minreq=3528 > Using sample spec 's16le 2ch 44100Hz', channel map 'front-left,front-right'. > Connected to device alsa_output.default (index: 0, suspended: no). > Stream started. > Time: 1.126 sec; Latency: 2005612 usec. > > The last line is interesting: here the "Time" counter keeps going up, > and the latency changes constantly, but stays approximately the same. > > Now if I play the same file without the PULSE_SERVER prefix, i.e. by > using a tunnel, then things look like this: > > $ paplay --verbose song.wav > Opening a playback stream with sample specification 's16le 2ch > 44100Hz' and channel map 'front-left,front-right'. > Connection established. > Stream successfully created. > Buffer metrics: maxlength=4194304, tlength=352800, prebuf=349276, minreq=3528 > Using sample spec 's16le 2ch 44100Hz', channel map 'front-left,front-right'. > Connected to device tunnel.dietpi-music.local.alsa_output.default > (index: 19, suspended: no). > Stream started. > Time: 0.000 sec; Latency: 108373832 usec. > > I do get playback. But in this case, that Time counter is stuck at > 0.000 seconds (it never increments). Furthermore, the Latency counter > keeps going up (strictly increasing). The final number when the song > playback finishes is approximately the same as the length of the song > (309346656 usec). > > The other things I've observed: playback of a YouTube video in > Firefox, which uses PulseAudio. It works completely fine when > direct-connected. But when using the tunnel, sometimes playback > completely hangs (like a network timeout); sometimes the video will > play, but after a random amount of time, it will stop, or reset itself > back to the beginning. > > I have this program "Transcribe!", which is gstreamer based. One > feature this program has is a
[pulseaudio-discuss] Tunnel vs direct connect to remote PA server - tunnel unreliable
I posted recently about this under the subject "Networking and volume control", but thought I'd start a new thread, as my focus is now less about volume, and more about getting reliable playback on a tunnel. Here's the setup: I have PulseAudio running on a Raspberry Pi, intended to be a music server for my office workstation/PC. The problem I'm having is: everything seems to work fine, as expected, when I direct connect from my PC to the RPI using PULSE_SERVER. However, on my workstation, I regularly need to switch between the RPI server and local sound devices, so direct connect is not appropriate for my use case. But I'm having issues with reliable playback when using a tunnel. If I play a wav file using paplay prefixed with PULSE_SERVER (i.e. direct connection), then things seem to work as expected: $ PULSE_SERVER=dietpi-music paplay --verbose song.wav Opening a playback stream with sample specification 's16le 2ch 44100Hz' and channel map 'front-left,front-right'. Connection established. Stream successfully created. Buffer metrics: maxlength=4194304, tlength=352800, prebuf=349276, minreq=3528 Using sample spec 's16le 2ch 44100Hz', channel map 'front-left,front-right'. Connected to device alsa_output.default (index: 0, suspended: no). Stream started. Time: 1.126 sec; Latency: 2005612 usec. The last line is interesting: here the "Time" counter keeps going up, and the latency changes constantly, but stays approximately the same. Now if I play the same file without the PULSE_SERVER prefix, i.e. by using a tunnel, then things look like this: $ paplay --verbose song.wav Opening a playback stream with sample specification 's16le 2ch 44100Hz' and channel map 'front-left,front-right'. Connection established. Stream successfully created. Buffer metrics: maxlength=4194304, tlength=352800, prebuf=349276, minreq=3528 Using sample spec 's16le 2ch 44100Hz', channel map 'front-left,front-right'. Connected to device tunnel.dietpi-music.local.alsa_output.default (index: 19, suspended: no). Stream started. Time: 0.000 sec; Latency: 108373832 usec. I do get playback. But in this case, that Time counter is stuck at 0.000 seconds (it never increments). Furthermore, the Latency counter keeps going up (strictly increasing). The final number when the song playback finishes is approximately the same as the length of the song (309346656 usec). The other things I've observed: playback of a YouTube video in Firefox, which uses PulseAudio. It works completely fine when direct-connected. But when using the tunnel, sometimes playback completely hangs (like a network timeout); sometimes the video will play, but after a random amount of time, it will stop, or reset itself back to the beginning. I have this program "Transcribe!", which is gstreamer based. One feature this program has is a live waveform of the left and right channels, which updates in real-time as the song plays back. When I use this program with PULSE_SERVER (i.e. direct-connect to the RPI) it works as expected. But when using the tunnel, I do get playback, but that waveform is static, not updating in realtime as it's supposed to. All these things together make me think that the tunnel appears to be a "one way" construct. It looks like I can send data to the tunnel (and get playback), but it seems like no data comes back. I assume the PulseAudio protocol is two-way, obviously you need to send audio data to the server, but presumably the server needs to send back acknowledgements and other status information. Thanks! Matt ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Networking and volume control
On Fri, Nov 6, 2020 at 1:10 PM Matt Feifarek 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Networking and volume control
I posted about this earlier, but now am facing a different problem.
Recap from original post:
I have PulseAudio set up on a Raspberry Pi as a sound server. The RPi
is connected to a USB DAC, which has hardware volume control
capabilities. This is what I have in my /etc/pulse/default.pa:
load-module module-alsa-sink control='D70 '
Note: I am deliberately NOT loading module-udev-detect, otherwise
PulseAudio reverts to software volume control. (The device is a
Topping D70, and the space between the zero and the quote above is
deliberate.)
Now, on the client, if I do this:
# PULSE_SERVER=rpi_server_hostname pavucontrol
Everything works as expected. That is, I have an output device
("D70") whose hardware volume I can control with pavucontrol. So I
went ahead and put "default-server = rpi_server_hostname" in my
~/.pulse/client.conf. Then all my apps route sound to the RPi.
But then I realized that config makes the RPi the *only* sound device
I can use on my PC. Sometimes I plug in other devices (e.g. webcam,
headphones) directly to the PC, and those get ignored with the
"default-server" config in place.
So it looks like one solution is to remove the "default-server" config
on the client, and use zeroconf/avahi so that the client can
automatically discover the RPi server as another output device, and
co-exist with local devices.
I set this up, basically by loading the "module-zeroconf-discover" on
the client PC, loading "module-zeroconf-publish" on the RPi server,
and running the avahi daemon on the server. With this in place, I do
see the RPi server showing up as an output device on my PC. However,
it doesn't work: I can't get any sound to come from it. Furthermore,
the volume control doesn't have any effect either. (I can play sounds
via MPD running locally on the RPI server. I can adjust the volume in
an MPD client. I can adjust volume from my PC using pavucontrol only
when using PULSE_SERVER or default-server, but not with the zeroconf
config I'm trying to get working.)
My suspicion is the zeroconf is only working enough to advertise the
device as available, but not advertising enough info to actually make
the device usable.
My other thought is that, given how I had to explicitly configure the
control on the server side, maybe I need to do a similar explicit
config on the client side?
I don't know if this helps, but maybe it offers a clue: on the client
PC, running "pactl list sinks" with and without being prefixed by
PULSE_SERVER:
$ PULSE_SERVER=dietpi-music pactl list sinks
Sink #0
State: RUNNING
Name: alsa_output.default
Description: D70
Driver: module-alsa-sink.c
Sample Specification: s32le 2ch 44100Hz
Channel Map: front-left,front-right
Owner Module: 5
Mute: no
Volume: front-left: 5727 / 9% / -63.51 dB, front-right:
5727 / 9% / -63.51 dB
balance 0.00
Base Volume: 65536 / 100% / 0.00 dB
Monitor Source: alsa_output.default.monitor
Latency: 22567 usec, configured 24988 usec
Flags: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY
Properties:
alsa.resolution_bits = "32"
device.api = "alsa"
device.class = "sound"
alsa.class = "generic"
alsa.subclass = "generic-mix"
alsa.name = "USB Audio"
alsa.id = "USB Audio"
alsa.subdevice = "0"
alsa.subdevice_name = "subdevice #0"
alsa.device = "0"
alsa.card = "1"
alsa.card_name = "D70"
alsa.long_card_name = "Topping D70 at
usb-:01:00.0-1.2, high speed"
alsa.driver_name = "snd_usb_audio"
device.bus_path =
"platform-fd50.pcie-pci-:01:00.0-usb-0:1.2:1.0"
sysfs.path =
"/devices/platform/scb/fd50.pcie/pci:00/:00:00.0/:01:00.0/usb1/1-1/1-1.2/1-1.2:1.0/sound/card1"
udev.id = "usb-Topping_D70-00"
device.bus = "usb"
device.vendor.id = "152a"
device.vendor.name = "Thesycon Systemsoftware & Consulting GmbH"
device.product.id = "8750"
device.product.name = "D70"
device.serial = "Topping_D70"
device.string = "default"
device.buffering.buffer_size = "705600"
device.buffering.fragment_size = "352800"
device.access_mode = "mmap+timer"
device.description = "D70"
alsa.mixer_name = "USB Mixer"
alsa.components = "USB152a:8750"
device.icon_name = "audio-card-usb"
Formats:
pcm
Versus running without the PULSE_SERVER environment:
$ pactl list sinks
Sink #0
(snipped for brevity - my HDMI monitor, which has sound output
capabilities)
Sink #1
State: SUSPENDED
Name:
Re: [pulseaudio-discuss] System-wide PulseAudio instance with realtime priority as non-root from systemd
On Sat, Oct 31, 2020 at 7:44 AM Jürgen Herrmann wrote: > What happens if you start the pulseaudio daemon in the console? Do you get rt > scheduling then? I would check that first to see if pulsesudio is configured > correctly. If that works you're probably better off asking the question in > the systemd list then... Good point. I am starting it from the CLI, running as root. And still I don't get realtime scheduling policy. # /usr/bin/pulseaudio --daemonize=no --disallow-module-loading --disallow-exit=yes --disable-shm=no --verbose --realtime=yes And in another terminal: # chrt -p `pgrep pulseaudio` pid 3920's current scheduling policy: SCHED_OTHER pid 3920's current scheduling priority: 0 With the following in my /etc/pulse/daemon.conf: allow-module-loading = no daemonize = no avoid-resampling = yes enable-shm = yes allow-exit = no realtime-scheduling = yes realtime-priority = 10 resample-method = soxr-mq flat-volumes = no I commented out everything in daemon.conf, and re-ran using the same CLI as above (just to eliminate a variable). Still not getting a realtime scheduling policy. Thanks, Matt ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Networking and volume control
On Sat, Oct 31, 2020 at 5:16 AM Tanu Kaskinen wrote: > > On Fri, 2020-10-30 at 17:28 -0500, Matt Garman wrote: > > I have PulseAudio set up on a Raspberry Pi as a sound server. The RPi > > is connected to a USB DAC, which has hardware volume control > > (...) > > The volumes shown in vlc and pavucontrol start out the same. And if I > > raise the volume in vlc, the slider in pavucontrol makes a > > corresponding change (as expected). > > > > However, if I *lower* the volume in vlc, the volume in pavucontrol > > stays the same. > > Which volume? The stream volume (Playback tab) or the device volume > (Output Devices tab)? I would expect the stream volume to be always in > sync, but if you have flat volumes enabled (which you probably do, > judging from your description), then increasing the vlc volume will > increase the device volume if necesssary, but lowering the vlc volume > will not affect the device volume in pavucontrol. In pavucontrol, in my original email, I was referring to the device volume (Output Devices tab). At the time, I didn't even think to check the stream volume. Since posting, I did discover the flat volume config option, and have disabled it. (I didn't check the pavucontrol stream volume sync with vlc when flat volume was still enabled.) At any rate - now that flat volume is disabled, the behavior is much more intuitive (at least to me!). Thank you! Matt ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Networking and volume control
On Sat, Oct 31, 2020 at 4:11 AM Karsten wrote: > Am 30.10.20 um 23:28 schrieb Matt Garman: > > I have PulseAudio set up on a Raspberry Pi as a sound server ... > > I would be fine to use PulseAudio in the future for use with ham applications > like fldigi. > Do you have experience to use PulseAudio without running an desktop and > pavucontrol? > Is it possible or maybe to start the desktop only for configuration? > Where and how is the configuration of PulseAudio saved? My understanding is that PulseAudio never explicitly *needs* a desktop environment for running or configuration. Like many traditional Unix daemons, the config is stored in text files on the filesystem. Most of these are in /etc/pulse, at least for system-wide config and defaults. Per-user config goes in ~/.pulse/ or ~/.config/pulse. I believe there may be other paths the daemon searches for configs, but /etc/pulse is a typical starting point. For my Raspberry Pi, I just ssh into it and do all the configuration using a text editor. Alsa definitely has commandline tools and text-based GUIs for things like volume adjustment and playback (e.g. amixer, aplayer, alsamixer). I don't know offhand if PulseAudio has similar text-based tools, but I'd be surprised if it didn't! ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] System-wide PulseAudio instance with realtime priority as non-root from systemd
It appears it was a systemd config issue, rather than an issue with pulse. In addition to updating /etc/security/limits.conf, I also needed to add the following to the [Service] stanza in my pulseaudio service file: LimitRTPRIO=95 LimitNICE=-19 But I still cannot get realtime (fifo) scheduling to work. I additionally have this in my Service stanza: CPUSchedulingPolicy=fifo And this in /etc/pulse/daemon.conf: realtime-scheduling = yes But still not getting realtime priority: # chrt -p `pgrep pulseaudio` pid 1203's current scheduling policy: SCHED_OTHER pid 1203's current scheduling priority: 0 Thanks! On Fri, Oct 30, 2020 at 5:35 PM Matt Garman wrote: > > On Fri, Oct 30, 2020 at 5:17 PM Jürgen Herrmann wrote: > > Look here: > > https://t-5.eu/hp/Software/Pulseaudio%20Crossover%20Rack/OnlineHelp/#scheduling > > Hi Jürgen, thank you for the quick reply. But either I'm missing > something, or that says to do exactly what I've already done.. > Realtime scheduling works when run from the commandline using > "runuser" (i.e. so I don't run as root). But when launched from > systemd, setting the realtime priority fails (setrlimit() operation > not permitted). > > Thanks again, > Matt ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] System-wide PulseAudio instance with realtime priority as non-root from systemd
On Fri, Oct 30, 2020 at 5:17 PM Jürgen Herrmann wrote: > Look here: > https://t-5.eu/hp/Software/Pulseaudio%20Crossover%20Rack/OnlineHelp/#scheduling Hi Jürgen, thank you for the quick reply. But either I'm missing something, or that says to do exactly what I've already done.. Realtime scheduling works when run from the commandline using "runuser" (i.e. so I don't run as root). But when launched from systemd, setting the realtime priority fails (setrlimit() operation not permitted). Thanks again, Matt ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Networking and volume control
I have PulseAudio set up on a Raspberry Pi as a sound server. The RPi is connected to a USB DAC, which has hardware volume control capabilities. This is what I have in my /etc/pulse/default.pa: load-module module-alsa-sink control='D70 ' Note: I am deliberately NOT loading module-udev-detect, otherwise PulseAudio reverts to software volume control. (The device is a Topping D70, and the space between the zero and the quote above is deliberate.) Now, on my Linux workstation, from a terminal, I set PULSE_SERVER=hostname_of_my_rpi. Then I launch two applications: vlc and pavucontrol. The volumes shown in vlc and pavucontrol start out the same. And if I raise the volume in vlc, the slider in pavucontrol makes a corresponding change (as expected). However, if I *lower* the volume in vlc, the volume in pavucontrol stays the same. This is a huge problem: say I temporarily raise the volume in vlc, and mistakenly set it too loud. I lower it to where it should be. Now I quit vlc. The actual volume now "jumps" back up to where it's stuck in pavucontrol! So if I'm not aware of this, the next app that uses PulseAudio will be way too loud. Now, I re-open vlc. I use pavucontrol to lower the volume to zero. If I raise the volume with pavucontrol, it also goes up in vlc, but by a different amount. I just raised the volume to 54% in pavucontrol, but it's showing 22% in vlc. (Whereas, as I noted above, when I raised it with vlc, the percentages were in lock-step with both programs.) Furthermore, if I raise the volume in vlc, nothing happens (i.e. no perceptible change in volume) until I hit 54% in vlc! Any thoughts on what's going on here? Thanks! ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] System-wide PulseAudio instance with realtime priority as non-root from systemd
My use case is as follows: I am trying to set up a Raspberry Pi as a sound server for my Linux PC. My Linux PC will use PulseAudio's networking capability to send the audio to the Raspberry Pi, which is connected to a stereo system. All the examples I've found online for doing this seem to suggest running the PulseAudio instance on the RPi in system mode. But with all the warnings about system mode, I thought I'd try to achieve this running Pulse in user mode. Furthermore, I want to have Pulse start automatically at boot time on the RPI, and run with real time priority. I want PulseAudio to run as user "pulse". I have this in /etc/security/limits.conf: pulse - rtprio 90 pulse - nice-19 And this in /etc/pulse/daemon.conf realtime-scheduling = yes realtime-priority = 5 And it seems to work as expected when launched from the CLI: # runuser -u pulse -- /usr/bin/pulseaudio --daemonize=no --disallow-module-loading --disallow-exit=yes --disable-shm=no --verbose Pulse prints this when starting: I: [pulseaudio] core-util.c: Successfully gained nice level -11 And looking at the process via "top" or "ps" shows that it is indeed running as the user "pulse". I have this in my systemd service file: [Service] User=pulse Group=pulse Type=simple BusName=org.pulseaudio.Server ExecStartPre=/bin/mkdir -p /var/run/pulse ExecStartPre=/bin/chown -R pulse:pulse /var/run/pulse ExecStart=/usr/bin/pulseaudio --daemonize=no --disallow-module-loading --disallow-exit=yes --disable-shm=no --verbose Restart=always And when I to "systemctl start pulseaudio", it starts, but not with realtime priority, and I have this in journalctl: Oct 30 17:09:00 dietpi-music pulseaudio[1104]: I: [pulseaudio] main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not permitted Oct 30 17:09:00 dietpi-music pulseaudio[1104]: I: [pulseaudio] main.c: setrlimit(RLIMIT_RTPRIO, (9, 9)) failed: Operation not permitted What am I missing? Thanks, Matt ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
