Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Linux audio can be a pain to get setup, but once you've got it setup you can do some pretty cool things. I set something up similar the other day with pulseaudio and a Bluetooth headset. I used it to route the headset channel output on mixxx to the Bluetooth headset and the master output through the speaker output. Sadly, the latency was too much to actually mix and beatmatch properly, but it was a fun exercise and just the fact I could do it was pretty cool.


I wonder if it could work with modern AptX low-latency headsets.


Yes, but you need a different repo [1] for that. The default one supports only SBC, this one adds support for AAC, AptX, AptX-HD, and LDAC. There's third party packages for a myriad of OSes.

[1] https://github.com/EHfive/pulseaudio-modules-bt


Huh, I managed to get AptX working using just a small patch for BlueZ, but I guess that would work too.


Pulse has latency adjustment so devices can compensate for latency.

When using combine module to output to multiple devices, do drop the sync latency fr the default 10s. Especially if it's a BT device. Turned it fr a nightmarish hell of constantly drifting terrible audio to just working multiple devices output for me.


Latency compensation, not magic latency elimination. The latter is not possible :-)

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. But when you're trying to get real-time audio to respond to user input (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. 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. mixxx or Ardour).

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. 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. 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: