I’m announcing Overwitch, a JACK client for Overbridge 2 devices. It has only been tested on Linux but it should work on every system that is using JACK as the audio server and has support for the libusb library.
It’s more than usable at the moment for monitoring and recording into Ardour with a RT kernel with a 64 frames buffer.
This project is based on the amazing work of @droelf in dtdump and snd-digitakt and also includes some ideas and code from the awesome zita resampler by Fons Adriaensen.
Overwitch latency is below 6 ms when using 64 frames buffer in JACK for similar sample rates.
Currently, it has some limitations.
Only a single instance of Overwitch can be run at the same time. If you have several devices, use only one at a time for now. This happens because the device is detected automatically. This surely will change in the future.
Only Digitakt and Digitone are supported but for every device working alike we could add a new device description that could hopefully work. Take a look at the README.md file and the source code for more information about this.
No MIDI support yet but I’m starting to think about the implementation as the reverse engineering is alredy done.
It is unknown if Overbridge 1 devices will work but you can try it out using the same approach above.
No UI. Perhaps a minimal status window could be useful. But the goal of this project is not to provide a full featured visual interface like Overbridge is.
This seems like a cool project. Would be pretty cool to be able to multitrack more than the two tracks you can get out of USB Audio. I’ve tested that compiling does work on Arch Linux, but I haven’t gotten the program to work on my system quite yet.
When I run it without sudo, it cannot find my device:
ERROR:overwitch.c:482:(overwitch_run): Device error: no matching usb device found
When I run it with sudo, it has issue finding JACK (maybe because I’m running JACK in user space?):
DEBUG:overbridge.c:337:(overbridge_init_priv): Device: Digitone
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
Automatic start of JACK server is disabled at configure time
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
ERROR:overwitch.c:489:(overwitch_run): jack_client_open() failed, status = 0x11
ERROR:overwitch.c:493:(overwitch_run): Unable to connect to JACK server
EDIT: This is a USB permissions issue and I was able to solve it temporarily running sudo chmod a+w /dev/bus/usb/003/069.
There is no need to run Overwitch as root. If anyone has problems like this it’s just a matter of permissions and running as root will not work as JACK would need to be run as root as well and probably other programs too.
Trying this out on some other Elektron devices. ARM2 works really well. Also tried out the Analog Heat MK2 with less success. The audio coming from the computer has some bit weirdness. For reference, this is the DESC struct I used:
I’m trying to wrap my head around how some of the JACK stuff here works. It seems the limit for the JACK buffer size is 128. What’s the reason for this?
That limitation exists because, to make things easier, at some point in the development I restricted the JACK buffer size to be smaller than the Overbridge one, which at the moment is always 168 frames (3.5 ms). Also, 256 plus 168 are almost 9 ms, which is quite a lot.
I want to remove this in the future but I’m leaving it for now and I’d like to check if there is a way to reduce the Overbridge frames.
My plan for now is to add some small changes to the code (remove callbacks and improve accuracy of time calculations) and release version 0.2 once every device had been added to Overwitch.
Once we get there, we’ll decide about the UI and implement a way to choose a device so multiple instances of Overwitch could be run. And later I’ll try to add MIDI and try to improve the latency and add more buffer length options. This is my short term plan but I’m open to suggestions.
I thought Analog Heat was a 2x2 Overbridge device but after looking around it’s not clear at all.
Can anyone here confirm that from the Overbridge POV it’s a 4 outputs and 2 inputs device? In a video I’ve just watched is displayed as a 4x4 interface in the Overbridge Control panel.
And I have noticed that samples are 24 bit values but I have treated as 32 bits. I have to check this.
Just bought an AHmk2 and me and others reported OB issues. I noticed there goes something wrong with the audio from pc to device. Elektron have replied on someone’s ticked and replied that they are aware of this “bug” and hoping fix it in a future update. This might be the issue? Dunno
2 inputs and 4 outputs is what gets Overwitch to run without errors.
On Overbridge, there seems to be {"Output L", "Output R", "FX Send L", "FX Send R"} and {"Input L", "Input R", "FX Send L", "FX Send R"} but 4x4 throws a “No more JACK ports available” error on Overwitch.
EDIT: one of the sends should be receive…
Changing the names to the correct-er ones gets a more predictable buffer overflow in 4x4.
Overwitch will never work well unless the description of the device matches the data that is being sent and received. So it has to be a 4x4.
The error you’re having is thrown because JACK couldn’t create the port. Probably the message is misleading but JACK is definitely failing at registering the port.
Firstly, there is the latency. We want to keep this to the minimum but perhaps the RPi needs to work with larger buffers than a state of the art PC. This depends on the architecture, chipset, USB driver, etc. more than the raw power. A RT kernel might help with this.
Then, there is the computing power. At the moment, the algorithm uses only the 4% of a CPU in my case. There are a few resampling algorithms to choose from so this could be parameterized if we need to use a faster one.
Finally, there are a few things to consider for the ARM architecture. We want to disable dummy cores (see the README.md), because this can cause problems in RT applications and I’m not sure it this would be possible. Besides, ARM uses something called big.LITTLE that is the name they use to indicate that not all cores are equal, which might cause trouble too. But this depends on the actual micro.
I can not go deeper than this.
But the best way to know is to try it out. I think it could work.
Overwitch will never work well unless the description of the device matches the data that is being sent and received. So it has to be a 4x4.
It is only true when sending data to the device because the device expects a certain amount of bytes for each USB transfer. If we are processing the received data, it is safe to ignore some of the tracks, which is what you’re doing here.
However, let’s create an issue in GitHub and see why you’re having that buffer overflow.
Interesting! So this would explain why things sound weird on the A4 (outputs: main 1/2 + 4 synth tracks = 6; not sure what the A4 does with those…) and the AR (outputs: main 1/2 + Main FX 1/2 + BD + CD + RS/CP + BT + LT + MT/HT + CH/OH + CY/CB = 12) as well.
After installing Overwitch, in ordet to allow users to use the devices create a file called /etc/udev/rules.d/elektron.rules with the following content. This allows us to use any device from Elektron.
