4 ms·

Maintainer of a project in the linux audio space here. The simplified view is that for pro-audio pulseaudio is the enemy. It is not built for low latency, it is

Maintainer of a project in the linux audio space here. The simplified view is that for pro-audio pulseaudio is the enemy. It is not built for low latency, it is a complex beast to tune, it can be opaque to debug, and some defaults are not ideal (e.g. resampling behavior). If you are having problems with xrun like events then I would start by trying to reduce how much involvement pulseaudio can have on the pipeline. In many cases linux audio can just work, but when it doesn't the debugging process can end up getting somewhat involved. There are a few places where you might have some luck with more detailed debugging like the linuxmusicians forum, the linux-audio-user mailing list, or one of several IRC channels on freenode (e.g. #jack ).

nickjj 8y ago
That's the interesting thing though. According to Jack I have no xruns with 512/2, but the pops remain (but only on Linux because using the same hardware, same USB ports, etc. on Windows has no pops). I'm just recording my voice in 1 line of the Scarlett, so 50-100ms of latency is no problem. You ever hear of a case where pops were coming in quite often but it wasn't related to xruns reported by Jack? Thanks for the heads up on #jack, I didn't even know they had an IRC channel, but in theory I should be able to pull this off without Jack too since I'm not doing anything fancy (such as redirecting sound through a DAW)? Still, pops happened without Jack too.
- fundamental 8y ago
  Having pops without jack indicates that either some other software layer is choking (e.g. pulse if the audio is still routed through it) or a hardware issue. You indicate that the hardware is without issue elsewhere, so that leaves the linux ALSA driver/driver settings, pulse (if it's interfering), jack, or the recording app. I do recall some mentions of a few of the Scarlett devices having quirks in the past, though I haven't personally been all that involved in those discussions. If jack or the recording application (connected to jack) were causing the issue then you should see an xrun reported from jack which makes me think that there's the possibility that it's being unexpectedly routed around via pulse (which can cause all sorts of shenanigans) or it's a know ALSA level driver quirk with respect to the device. The latter is unlikely as you're indicating that this is a USB device (IIRC the firewire ones were the more fussy ones). Even if you're not striving for low latency I would recommend some of the audio communities as they're likely to have stressed the same device a fair bit and may have encountered similar issues.
  - nickjj 8y ago
    Thanks. Is there any chance the Windows driver has some special sauce to deal with hardware defects that alsa / pulseaudio aren't aware of? Maybe some crazy edge case defects (since it's not affecting everyone with a Scarlett). I think I am still using pulse mainly because I installed qjackctl and pulseaudio-module-jack, but my audio devices according to pavucontrol were Jack, but it's still being routed through pulse right? I Googled to the end of the world on this device with Linux but came up empty handed. It was just a few success stories.
    - fundamental 8y ago
      Typically that approach setups up jack as the primary device user and pulse as the secondary. Your setup involves a usb audio device in addition to what I assume is some builtin audio device on your desktop/laptop. JACK's server only takes full control over a single device, so it's possible that JACK took over something other than your Scarlett leaving a different routing mechanism to shuttle data from the Scarlett to it. As that's a mouthfull, what may be happening is: Dev A <-> JACK <-> Pulse <-> Dev B If that's happening then you'd want to switch the setup to: Dev B <-> JACK <-> Pulse <-> Dev A or Dev A <-> JACK <--+--> Zita-ajbridge <-> Dev B | +--> Pulse Per the windows driver, I have no idea and likely neither do ALSA devs since the source is not available there. If the Scarlett driver is a standard usb-audio device, then it likely should be exceptionally robust and very similar across operating systems.
      - nickjj 8y ago
        You are correct in that I also have a built-in sound card that's on the motherboard, but currently there's no microphone connected to it. I also had my headphones connected directly to the Scarlett. When Jack was wired up with that pulse module plugin, if I talked into my the mic, pavucontrol showed the input bar jumping around. Does that mean it was operating on the correct mic? When I used OBS' jack client, it also picked up the Scarlett's mic once I wired it through qjackctl. I know on Windows I was getting pops and cracks until I installed the Scarlett driver and specifically set the buffer to 512. Any other value would produce pops on Windows (even worse with 1024 which is weird).
- saltcured 8y ago
  I don't know Jack, but it might be worth checking whether something like buggy automatic power management is suspending and resuming the relevant USB path during acquisition... It is possible to disable the power management at several levels. The "powertop" utility is a convenient way to play with the top-level device/driver tunables. And the /sys/bus/usb filesystem has a power/autosuspend setting for individual devices.
viraptor 8y ago
Is there any tool that you can point at your pulseaudio and it would walk the whole configuration, trying you which parts are likely to cause delays? (With suggestions)
- fundamental 8y ago
  I don't know. I do not typically use pulseaudio on my systems. I do have tools which are built to check source code for low latency compatible C/C++, but it sounds like you want something to inspect a running pulse audio daemon.
  - amaccuish 8y ago
    What are your views on PipeWire?
    - fundamental 8y ago
      Possibly a good direction for consumer audio. Currently it lacks feedback (at the design level) for it to build into something useful for pro audio.

nickjj 8y ago

That's the interesting thing though. According to Jack I have no xruns with 512/2, but the pops remain (but only on Linux because using the same hardware, same USB ports, etc. on Windows has no pops). I'm just recording my voice in 1 line of the Scarlett, so 50-100ms of latency is no problem. You ever hear of a case where pops were coming in quite often but it wasn't related to xruns reported by Jack? Thanks for the heads up on #jack, I didn't even know they had an IRC channel, but in theory I should be able to pull this off without Jack too since I'm not doing anything fancy (such as redirecting sound through a DAW)? Still, pops happened without Jack too.

fundamental 8y ago
Having pops without jack indicates that either some other software layer is choking (e.g. pulse if the audio is still routed through it) or a hardware issue. You indicate that the hardware is without issue elsewhere, so that leaves the linux ALSA driver/driver settings, pulse (if it's interfering), jack, or the recording app. I do recall some mentions of a few of the Scarlett devices having quirks in the past, though I haven't personally been all that involved in those discussions. If jack or the recording application (connected to jack) were causing the issue then you should see an xrun reported from jack which makes me think that there's the possibility that it's being unexpectedly routed around via pulse (which can cause all sorts of shenanigans) or it's a know ALSA level driver quirk with respect to the device. The latter is unlikely as you're indicating that this is a USB device (IIRC the firewire ones were the more fussy ones). Even if you're not striving for low latency I would recommend some of the audio communities as they're likely to have stressed the same device a fair bit and may have encountered similar issues.
- nickjj 8y ago
  Thanks. Is there any chance the Windows driver has some special sauce to deal with hardware defects that alsa / pulseaudio aren't aware of? Maybe some crazy edge case defects (since it's not affecting everyone with a Scarlett). I think I am still using pulse mainly because I installed qjackctl and pulseaudio-module-jack, but my audio devices according to pavucontrol were Jack, but it's still being routed through pulse right? I Googled to the end of the world on this device with Linux but came up empty handed. It was just a few success stories.
  - fundamental 8y ago
    Typically that approach setups up jack as the primary device user and pulse as the secondary. Your setup involves a usb audio device in addition to what I assume is some builtin audio device on your desktop/laptop. JACK's server only takes full control over a single device, so it's possible that JACK took over something other than your Scarlett leaving a different routing mechanism to shuttle data from the Scarlett to it. As that's a mouthfull, what may be happening is: Dev A <-> JACK <-> Pulse <-> Dev B If that's happening then you'd want to switch the setup to: Dev B <-> JACK <-> Pulse <-> Dev A or Dev A <-> JACK <--+--> Zita-ajbridge <-> Dev B | +--> Pulse Per the windows driver, I have no idea and likely neither do ALSA devs since the source is not available there. If the Scarlett driver is a standard usb-audio device, then it likely should be exceptionally robust and very similar across operating systems.
    - nickjj 8y ago
      You are correct in that I also have a built-in sound card that's on the motherboard, but currently there's no microphone connected to it. I also had my headphones connected directly to the Scarlett. When Jack was wired up with that pulse module plugin, if I talked into my the mic, pavucontrol showed the input bar jumping around. Does that mean it was operating on the correct mic? When I used OBS' jack client, it also picked up the Scarlett's mic once I wired it through qjackctl. I know on Windows I was getting pops and cracks until I installed the Scarlett driver and specifically set the buffer to 512. Any other value would produce pops on Windows (even worse with 1024 which is weird).
saltcured 8y ago
I don't know Jack, but it might be worth checking whether something like buggy automatic power management is suspending and resuming the relevant USB path during acquisition... It is possible to disable the power management at several levels. The "powertop" utility is a convenient way to play with the top-level device/driver tunables. And the /sys/bus/usb filesystem has a power/autosuspend setting for individual devices.

viraptor 8y ago

Is there any tool that you can point at your pulseaudio and it would walk the whole configuration, trying you which parts are likely to cause delays? (With suggestions)

fundamental 8y ago
I don't know. I do not typically use pulseaudio on my systems. I do have tools which are built to check source code for low latency compatible C/C++, but it sounds like you want something to inspect a running pulse audio daemon.
- amaccuish 8y ago
  What are your views on PipeWire?
  - fundamental 8y ago
    Possibly a good direction for consumer audio. Currently it lacks feedback (at the design level) for it to build into something useful for pro audio.