2-node-supercomputer.net 2020-05-23
I got a Tribit StormBox.
Out-of-the-box, there is a large lag of the bluetooth audio.
Tribit says to update the firmware on the speaker via USB. But, the only way they provide is to use their Windows program. What is a Linux user to do?
Cheat, of course!
And, no, not by using wine, which I tried at first. But by running Windows in a virtual machine.
But, first have a look at the USB interface that the StormBox exposes. We can see that the device exposes a manufacturer-defined interface with two bulk endpoints by issuing
$ lsusb -v -d 10d6:10d6The hex numbers are the vendor and product ID of the StormBox. One of the endpoints is an input endpoint, the other an output. Sounds reasonable. Sounds reverse-engineerable.
However, let’s not brick the brick. And to gather data, we need to update the firmware somehow anyway, right?
Therefore, enter qemu, a program that allows you to run a VM. And Microsoft allows you to test Windows for a bit as long as you have or create a Microsoft account. (I first was looking into recovering the Windows product key from my Windows 10 disk image that I preserved before I put Linux on my laptop, but perhaps more luck with that some other time.)
With going into the details, here is what I did. Basically, I followed the Gentoo wiki on creating a Windows hosting with QEMU. Get the virtio drivers from Fedora/Red Hat, and download a Windows installation ISO from Microsoft. To make it work, I also needed to enable KVM in the BIOS of my laptop first.
Then, pass-through the USB device to the VM with the vendor and product key as above, which was shown in the Archlinux wiki on QEMU. However, to run the VM as a normal user, I created a UDEV rule to change the OWNER and GROUP of the USB device, again see the Arch wiki.
Finally, the VM can be started up, and the Media Tool provided by Tribit can be used to update the firmware. Boom, done! Audio still lags, but only maybe 0.2 seconds or so.
Is audio lag a fundamental problem with bluetooth? Using the AUX cable input, there is no noticeable lag. So, it is definitely related to bluetooth. However, you would expect there to be some mechanism for a device to specify its lag, perhaps dynamically depending on interference. Does the bluetooth protocal allow that?
Turns out, yes, it does. It is called A/V sync, and has been around for awhile. However, bluetooth 5.0 seems to fix some remaining issues with it.