cross-posted from: https://discuss.online/post/34255100
Thought I’d create a distinct thread from the previous one asking about daily use, because I really do want to hear more on people’s pain points. Great to know people are generally sounding pretty positive in those posts who recently switched, but want to know your difficulties as well! This way old and new users can share their thoughts, hopefully to inspire a respectful discussion.
Can’t say I’ve had any latency or artifacting on modern Linux… are you running Pipewire? JACK?
Using pipewire. It depends on which settings I use for the sample and bit rate. On windows I can use almost any combination, and baring a few older games, there is no stuttering or breakup. In Linux I find only specific sample and bit rates work well. The others cause stuttering and audio drops.
Also changing sample and bit rates is not straightforward. I’ve found utils that help but the only reliable way I’ve found is to edit the configs then restart the service.
I haven’t gotten my hands dirty with this stuff specifically, but maybe you need to adjust buffer sizes to properly handle the different bit rates. Do you mainly see issues with higher combinations? The sample rate * bit depth is the important number, here. If you consider the problematic ones from that perspective, is there a threshold where anything under works fine but anything above has issues that get worse depending on how far above the threshold it is?
I’m not certain, but I believe the audio buffer is handled via a callback function that gets called when the audio buffer is some % close to empty, and then the program refills the buffer, plus some other overhead. That data left in the buffer sets the deadline for refilling the buffer; miss that deadline and the audio cuts out. Meet the deadline and audio is seemless.
A too small buffer will require the callback be called more often, and then the overhead can add up to missing deadlines. Alternatively, the % when it does the callback might need to be adjusted.
Another consideration is if your DAC doesn’t support the chosen sample rate and bits per sample, then there is probably another buffer of the supported size and a conversion from one to the other (and its own callback when that buffer gets low). That said, I don’t know if it’ll even list unsupported combinations because I’m having trouble thinking of a valid use case. But it’s technically possible, so maybe it is like that.
Anyways, those are what I’d be checking to debug this. If it is a setup problem, it won’t likely ever go away on its own, unless better defaults get set for those bitrates, but the ideal values depend on your system’s performance, so if yours is on the weaker side, it might never change.
Most of what you said went a bit over my head. I have the Topping E2x2 audio interface. I did some testing of each setting combination on Windows. And it just works. I’m definitely using settings the hardware supports. Linux just doesn’t seem mature in this area.
Ok, I figured the hardware support bit would be a longshot anyways.
Whatever is going on, it is missing real-time deadlines for some reason. It could be the configuration results in too much work, or the audio work itself isn’t that bad but the priority is low enough that other less time-critical work is getting in the way.
But yeah, even if it is solvable, there should be good defaults to prevent it from happening in the first place. Annoying thing is that there might even be profiles where one would work for you, but they might be hidden deep in the terminal.