There are protocol limitations here. There have been very recent advances, that bring us to 40~60 ms, but they all root in Bluetooth 5 (officially announced jul

There are protocol limitations here. There have been very recent advances, that bring us to 40~60 ms, but they all root in Bluetooth 5 (officially announced july 2016 but holy fucking shit this adoption has been trashfire slow especially on pc) and it's incredibly confusing/difficult to understand which if any codecs have been able to take advantage of this possibility. It'd take me probably an hour to put together the basics on how available this is right now. But that should not affect your use case; playing movies should work fine, period, end of statement. The fact that there is latency to your speaker is something that an bluetooth or other audio pipeline should know, should be able to compensate for. PulseAudio (which your music players are almost certainly using, under pipewire or other) has great understanding of latency built in. If you do experience big audio latency, open up pavucontrol & adjust your device's latency, and that problem should go away. It should be semi-stable. But pulseaudio & pipewire both should, in a wide range of cirumstances, understand what the expected latency is & "just work." If you are on a videoconference, however, knowing that there's a second of latency doesn't help, won't bring things closer to real-time. It's still gonna be terrible. Newer specs, newer codecs could help significantly, but the audio daemon won't be able to help. Pulseaudio did have higher latency by default, tuneable (i think i'd tuned to using 2 frames of 16ms each = 32ms, pretty aggressive), but I think they've trimmed it significantly in very recent releases, but pipewire's architecture has allowed it to be significantly more aggressive.