I'm a little bit behind now - 1.20.1, compared to yesterday's 1.21.1 - so this might have been fixed already. Or it could be a problem in OBS and not the plugin. Anyway, I noticed that an audio source fade over 0.50 seconds has a pronounced "zipper" effect. I think I counted 5 distinct pops over that time. (Adv. SS is running every 50ms) Mute/unmute has a single pop that sounds about the same.
My use is probably more of a challenge than most, in that it's much harder to hide the "zipper" in the original content, because it's a pure sine wave that is filtered out later. It's digitally generated, so its own harmonic content (distortion) is practically zero, and the filter is digital with the same clock, both of which make it easy to pick back out of a mix like I'm doing. It's not meant to get to the speakers, but if it misbehaves, then the misbehavior does.
My reasons to do that are:
- The WebSockets weren't getting through reliably from one copy of OBS and Adv. SS to another, even on the same machine. Most of the time they would, but then it would miss one, and the incomplete transition would create an audio feedback loop. After several iterations that eventually ended up just spamming the connection constantly (which did work, but also made it hard to override the receiving end manually), I switched to an audio trigger instead of WebSockets.
- I'm using more audio channels now than OBS really supports. My end goal is stereo, but with different mixes going to different places, I need to keep things separate and not mix them too early. OBS does *not* do multichannel very well, despite having the option! Not when it's feeding a loopback to another app at least, instead of a direct stream or recording. So I moved the entire audio chain into the DAW, which means that I need to generate control signals from OBS to control the DAW.
So as it is now, my DAW generates a pure sinewave at the extreme end of the audio spectrum (doesn't matter which end; they both work the same, with the same problem), then OBS picks that up as two different global audio sources, pans them hard to either side, mutes or passes each one to make a 2-bit (4-state) "mode indicator", and mixes that with whatever legitimate soundtrack I have on its way out the Monitor and back to the DAW. The DAW then has a crossover to separate the audio from the control signal (same as the crossover in a home stereo or a pro PA rig, but much steeper / sharper / more aggressive to get some good separation). The audio goes on down that chain, and the control goes to some sidechains in the DAW to turn some things on or off like OBS used to, and to the other copy of OBS, where Adv. SS now uses the Audio condition instead of WebSockets to do the mode switch.
The problem is that the mute-pop - or series of pops from a fade-zipper - cover the entire audio spectrum regardless of the original content, and so they show up on the soundtrack side of the crossover and continue on down that chain, regardless of whether I use the top end or the bottom end of the spectrum. It's not harmonics of the original sine, which would be entirely above the original frequency (if it were, then a 20kHz sine would be a convenient way to fix it, but it doesn't). It's a completely new signal that has nothing to do with the original, I suspect because two consecutive samples have vastly different values.
I've also thought about treating this as an
XY problem and sending control signals directly from OBS to the DAW. Open Sound Control (OSC), for one example, or WebSockets again. But having seen what the WebSockets did originally, I still like the out-of-band audio idea a lot better!
OBS 29.0.2
Adv. SS 1.20.2
Ardour 6.9.0~ds0-1build1
Ubuntu Studio 22.04 LTS
