OB for Linux (sorta ;)

droelf · 2019-02-03T19:01:38.655Z

I sniffed the USB communication between my Digitakt and the Audio Capture Tool in the standalone version of the OT software, and came up with a simple command line tool which captures all 12 audio streams to a 12 track .WAV file. It should compile on every OS where libusb and libsndfile is available for. Somebody could write a driver or JACK (linux sound server) adapter based on this, and you could have your magic single-outs adapter box (think raspberry pi plus USB sound interface with 8 to 12 channels out for starters)
https://github.com/droelfdroelf/dtdump

Mod Edit : Moved to a more appropriate category to avoid confusion as it’s not Elektron Software per se, nor really Overbridge in the strictest sense

tnussb · 2019-02-03T19:06:53.134Z

Oh, wow. That’s really nice. Opens up a lot of DIY ideas

Thanx for sharing!

tnussb · 2019-02-03T19:13:19.488Z

Is there a reason why you call …

libusb_set_configuration(dt, 1)

twice in digitakt_init?

droelf · 2019-02-03T19:17:50.690Z

There is none. It was just in the init stuff I saw in the sniffer logs, and I initially just copied the whole sequence. Most likely this is not needed, pull requests are always welcome

tnussb · 2019-02-03T19:23:29.107Z

Guessed so. The rest looks quite straight forward. Really nice.

DoS · 2019-02-03T19:35:18.397Z

Amazing! I don’t have a Digitakt, but is it possible that something similar would work for the A4?

Hawk · 2019-02-03T19:36:39.293Z

Whoa nice work! This is really fun!

droelf · 2019-02-03T19:43:49.963Z

DoS:

would work for the A4?

I don’t know, as I see it, there are two kinds of machines now: The newer ones with USB2.0 have way enough bandwidth, they just stream all channels with 24 Bit resolution (even using 4 bytes for it, maybe stuffing them together uses to much compute power). The older ones with USB1.0 (such as the A4 I think) have to be configured for which channel to send in which resolution etc., then the data has to be parsed accordingly, still nothing that one could not get done.

Nevets · 2019-02-03T20:03:10.519Z

Awesome, well done and thanks for sharing. Will do some testing soon. Always fun to tinker with the RPi

droelf · 2019-02-03T20:22:22.458Z

BTW the USB bandwidth used is in the orders of 10MB/s, disk a little bit less, but could be a problem for slow SD cards.

Untitled · 2019-02-03T20:25:06.187Z

Thanks for the work. A small box that just record the digitakt would be awesome. Will definitely check it out and see if I can contribute.

kippertoffee · 2019-02-03T20:26:47.777Z

This is fantastic! Seriously nice work

srK · 2019-02-03T20:47:28.118Z

My man.

kippertoffee · 2019-02-04T05:46:42.094Z

Hey @droelf, any tips on where to start learning how to sniff usb and understand what you’re seeing?

handed · 2019-02-04T06:08:37.905Z

Seriously impressed by this. Awesome work.

droelf · 2019-02-04T06:59:12.902Z

kippertoffee:

Hey @droelf, any tips on where to start learning how to sniff usb

Wireshark (open source packet sniffer) supports already usb dissecting. The Linux kernel provides an interface for it to attach to (usbmon) and grab data from the hardware. Then I had the Elektron software running in a virtual machine. There is a quite interesting talk about reverse engineering usb drivers:

kippertoffee:

and understand what you’re seeing?

Luckily, we can control which channel is currently sending audio data: If you mute everything but one, playing a simple clean waveform (triangle, sine …) and then diffing consecutive packets, you can make out pretty easily the location of this specific channel’s data

skrzyp · 2019-02-04T07:00:04.005Z

At this point, what’s actually preventing Elektron from publishing some sort of protocol specification as it’s implemented on most of their currently manufactured devices?

I’m sure that won’t make them any $$$ loss, might even convince a bit more users

kippertoffee · 2019-02-04T08:52:21.829Z

Thanks a lot, I’ll have a watch

tnussb · 2019-02-04T10:19:01.851Z

skrzyp:

what’s actually preventing Elektron from publishing some sort of protocol specification

Nothing, I guess, but it’s simply additional work and it has some drawbacks when it got published. Nowadays too many feel entitled for everything. Keeping the “attack surface” small, isn’t a bad idea for a company (shitstorms can grow out of nowhere without any rational base).

Keeping such docs closed, helps heavily in staying agile, because you can change things in whatever way you want without thinking about 3rd parties.

Nevets · 2019-02-04T14:34:05.650Z

I’m trying to compile this on an arm64 board but getting some error:

root@aml:~/dtdump/build# LibUSB_ROOT_DIR=/lib/aarch64-linux-gnu/ cmake ../
-- Checking for module 'libusb-1.0'
-- Found libusb-1.0, version 1.0.21
-- LIBSNDFILE_INCLUDE_DIR='/usr/include'
-- LIBSNDFILE_LIBRARY=/usr/lib/aarch64-linux-gnu/libsndfile.so
-- LibUSB_INCLUDE_DIRS='/usr/include/libusb-1.0'
-- LibUSB_LIBRARIES=/usr/lib/aarch64-linux-gnu/libusb.so
-- Configuring done
-- Generating done
-- Build files have been written to: /root/dtdump/build
root@aml:~/dtdump/build# make
Scanning dependencies of target dtdump
[ 50%] Building C object CMakeFiles/dtdump.dir/dtdump.c.o
/root/dtdump/dtdump.c: In function ‘sighandler’:
/root/dtdump/dtdump.c:301:9: warning: too many arguments for format [-Wformat-extra-args]
printf("Shutting down ...\n",s);
^~~~~~~~~~~~~~~~~~~~~
[100%] Linking C executable dtdump
CMakeFiles/dtdump.dir/dtdump.c.o: In function `prepare_transfers':
dtdump.c:(.text+0x9c): undefined reference to `libusb_alloc_transfer'
dtdump.c:(.text+0xd0): undefined reference to `libusb_alloc_transfer'
CMakeFiles/dtdump.dir/dtdump.c.o: In function `free_transfers':
dtdump.c:(.text+0x120): undefined reference to `libusb_free_transfer'
dtdump.c:(.text+0x130): undefined reference to `libusb_free_transfer'
CMakeFiles/dtdump.dir/dtdump.c.o: In function `digitakt_init':
dtdump.c:(.text+0x22c): undefined reference to `libusb_set_configuration'
dtdump.c:(.text+0x25c): undefined reference to `libusb_set_configuration'
dtdump.c:(.text+0x28c): undefined reference to `libusb_claim_interface'
dtdump.c:(.text+0x2bc): undefined reference to `libusb_claim_interface'
dtdump.c:(.text+0x2f0): undefined reference to `libusb_set_interface_alt_setting'
dtdump.c:(.text+0x324): undefined reference to `libusb_set_interface_alt_setting'
dtdump.c:(.text+0x354): undefined reference to `libusb_clear_halt'
dtdump.c:(.text+0x384): undefined reference to `libusb_clear_halt'
CMakeFiles/dtdump.dir/dtdump.c.o: In function `usb_shutdown':
dtdump.c:(.text+0x408): undefined reference to `libusb_close'
dtdump.c:(.text+0x414): undefined reference to `libusb_exit'
CMakeFiles/dtdump.dir/dtdump.c.o: In function `prepare_cycle':
dtdump.c:(.text+0x5d8): undefined reference to `libusb_submit_transfer'
dtdump.c:(.text+0x600): undefined reference to `libusb_submit_transfer'
CMakeFiles/dtdump.dir/dtdump.c.o: In function `main':
dtdump.c:(.text+0x6a4): undefined reference to `libusb_init'
dtdump.c:(.text+0x778): undefined reference to `libusb_open_device_with_vid_pid'
dtdump.c:(.text+0x7fc): undefined reference to `libusb_handle_events'
collect2: error: ld returned 1 exit status
CMakeFiles/dtdump.dir/build.make:96: recipe for target 'dtdump' failed
make[2]: *** [dtdump] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/dtdump.dir/all' failed
make[1]: *** [CMakeFiles/dtdump.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2