Ubuntu Studio 24.04, OBS 32.0.0: Audio Monitor through PipeWire: Brickwall-lowpassed at 2kHz

[AaronD]

Trying to fix the ever-increasing latency problem on certain sound cards, by connecting OBS to a virtual thing and then the virtual thing goes to the actual hardware. (clock drift, that OBS hasn't handled correctly for years...)

But now I have a different problem:

The upper blue and red traces are the noise generator's output. The lower traces are from OBS. Re-patching to bypass OBS but keep the two virtual devices, gives a flat trace.

OBS's settings:

The recording is okay, so it's just the monitor that has a problem:

Anyone else had this problem and solved it?

 

[stephematician]

The audio library within OBS is damn near arcane - this would be quite difficult to debug and fix either problems e.g. the ever-increasing latency issue or that high shelf-like output. Good find! And good luck.

 

[AaronD]

The audio library within OBS is damn near arcane

I know. The understandable part is that the official dev team hasn't had an audio guy for all those years and (perhaps wisely, given the circumstances) hasn't tried to fix it.

The frustrating part is their defense of the ever-increasing latency in terms of asynchronous networking! THIS IS NOT A NETWORK! It's supposed to emulate a physical wire in the same physical space. Noticeable latency has no place there, even if you have to compromise other things to get rid of it.

No other app that I know has that problem, hence the virtual device in between: send OBS to something else that has the same clock and is therefore okay, and let the something else handle the clock problem correctly.

Anyway, like I said, they don't have an audio guy, so their attempts to fix it will likely make it even worse, and so they haven't.

---

The routing as shown all the way up top here, would have worked...if it weren't for the 2k brickwall. The steepness and location suggest to me an anti-aliasing filter a decade too low. That filter is a required part of resampling:

1. Stuff an equal number of zeroes between original samples to get a really high sample rate that is a common multiple of both the input and output rates.
2. Lowpass to smooth it out, and gain it up to account for all the zeroes, often doing both in a single step.
   • For that matter, all 3 of these points can be condensed into a single step that doesn't look like anything useful at all until you've studied it for a long time.
   • The result of the lowpass should contain nothing consequential above half the new sample rate, and should not adversely affect anything audible. For 40-odd kHz sample rates, that's pretty steep! Hence the term, "brickwall".
3. Pick samples out at the new rate.

If OBS is resampling the Monitor output (surprised it does, since the clock problem suggests it doesn't), and it gets the filter frequency wrong by a decade or an order of magnitude (same thing), then that would explain the measured behavior.

And good luck.

Thanks.