> I still don't really understand Linux audio layers and how all this stuff works together I have a wireless microphone set on 2.4 using proprietary dedicated technology for this, and it still has noticeable latency (though just about usable for karaoke and such, but not ideal), because it has to introduce a fixed latency to allow for a retransmit budget in case of error. It's really, really hard to do wireless audio with low enough latency for live music, especially on 2.4GHz where you need error correction and retransmits because the band is always so congested. In either case, the Bluetooth issue is inherent to the protocol and codec and technology stack there, and there's no way to fix it. That's why for music production on Linux, you should be using JACK (or directly using ALSA from whatever source app you have, e.g.
games, or DJing or playing music), latency compensation just gives you the lowest common denominator, and PulseAudio isn't really any good at guaranteeing low latencies for these use cases anyway.
But when you're trying to get real-time audio to respond to user input (e.g. You can get audio to line up across different outputs when it is being played from a source with a large buffering capability, which is what PulseAudio does well. Latency compensation, not magic latency elimination.
0 kommentar(er)
