Maybe this explains why I had less issues on arm dev boards with emmc onboard. Yesterday I had both glitches on sd card and a network disk. I tested the sustained speeds on B+ wifi and it’s about 6-8mb/s. Should be enough on paper. Looking forward testing the new code
I pushed a new version! Major changes:
Moved the USB transfer handling in a separate thread, running at highest (real time) priority. Data is then written to disk in a lower prio thread, with lots of buffers in between (queue). Also, disk writes are forced at a constant frequency to avoid massive caching/“bursty” writes esp. on SD cards. Some stats are displayed during a run:
283775 kB - buff: 8192 - xrun: 0
287508 kB - buff: 8192 - xrun: 0
291682 kB - buff: 8192 - xrun: 0
^CShutting down …
Total stats: Buffers low: 7741 - Xruns: 0
“Buffers” is the current number oft free units in the queue (units: One USB transfer = 8kByte). The default length is set to 8096 items, but can be changed in the source if needed (overbridge.c line 20). Additionally, the time stamp in the sound data from the DT is checked an compared between packets, if some data got lost, the xrun counter is increased by one.
I recorded a few minutes on my raspberry without any xruns and checked each track for glitches … there are none
- Record to 12 single mono files
Start it with ./dtdump -s
Note: In the old version of the README, I forgot to add the cmake parameter for passing the optimization flag -O3 to the compiler, so remember to run it with
cmake …/ -DCMAKE_BUILD_TYPE=Release
Have fun …
Not all heros wear capes!
Will give the new version a go tonight. Thanks for your hard work
It might be helpful for others when there’s a documentation of your insights about the protocol. Maybe others are able to contribute to that. I’m thinking about a breakout-box to get the live audio of the single tracks out of my Digitone into a analog mixer.
The protocol spec, or more what is known of it so far, is already in the source comments I just updated it (number of blocks per USB transfer was wrong, added some details).
Duh. I didn’t looked at the headers
Thanks again for this awesome work!
Thanks @droelf it’s amazing and it works on the DIGITONE too !!!
I can have a dump of each track of the digitone and a track with the mix.
Just change this in the overbridge.c file
// we support only the Digitakt for now …
#define DT_VID 0x1935
#define DT_PID 0x0014
//#define DT_PID 0x000c
Then mkdir build cd build cmake ../ -DCMAKE_BUILD_TYPE=Release make and launch sudo ./dtdump GREAT !!!
Thanks koorenay, I modified the current code to simply try both PIDs (first digitakt, then digitone) during USB init and use the first available one. So it should work now on both devices. I do not have a tone unfortunately, so everyone is welcome to test (and send pull requests ).
Also, in partly related news, I created a kernel driver for overbridge
(should better be renamed to snd-overbridge now …) with both audio AND midi working, plus a modified version of the raspbian image build system
to integrate it in raspbian image builds. The idea is then to have something like Supercollider or PureData running on a Pi (or similar) which could then add some nice features, e.g. routing digit*s external inputs through some effects and mixing them down with the internal channels.
I really hope your work brings someone closer to making the device I crave.
My vision is a simple stand alone multi-out box that connects to the the Digi-x via usb and includes some kind of header that makes sense of the digital audio stream and spits each channel of audio out with a DAC and 1/4" jack per channel.
Thanks for your work!
This sounds like a pretty ideal for Elektron to produce at some point. It must be a consideration or have been discussed by them at some point… Reckon a lot of 'nauts would insta-buy!
I’d insta-buy two
don’t have a digitakt but your effort is really cool! <3 <3 <3
(and it didn’t take 6 months to get a release )
Just connect an audio interface with at least 8 outs to any decent laptop, install the OB2 beta version, and you’ve got that ideal device.
Yeah, I get that that’s the point of Overbridge and I’m sure that would be great for some people - but I don’t want to use a computer - especially when a small, simple dedicated break-out box could do the same job.
With things as they are in the world of computing, I wonder if Overbridge will even have a lifespan as long as Elektron’s hardware devices; it’s conceivable that it won’t. Regardless, a dedicated breakout box is exactly what some of us want, and it would ensure that the insane amount of time and resources Elektron have put into OB, could never become a completely wasted effort.
Furthermore, as Elektron customers, we’re all subsidizing Overbridge whether it’s something we’ll eventually use or not - a dedicated box would nicely share some of the benefits of that cost and labour to a broader user base.
For some of us there’s just something counter intuitive about Overbridge - a lot of people buy dedicated hardware to avoid non-dedicated computational devices; and I’m one of them. I didn’t buy either of the Digis in the hope that Elektron would make a break-out box (I bought them because they’re dope) but I sure as hell wouldn’t say no to (relatively) cheap, hassle free multi-outs.
IMHO it’s definitely not about “how the things are in the world of computing”. It’s about how you use/treat them. With some simple rules like:
- never connect it to the internet
- use it only for audio production
- don’t upgrade/update just for the sake of updating
your computer setup will last equally long as a dedicated hardware box. Of course you need to make sure to stay away from software which requires an online connection (license verifications or different stuff).
But other than that: it’s all about discipline. Just because a computer can do all kinds of stuff and you can install and run a zillion different apps, doesn’t mean you should when you want a stable system which may last a while.
You can definitely build a small form factor box which runs OB (and nothing else). Configure it to autostart everything needed and the usability isn’t far of what you would get (or pay) for a dedicated box.
Exactly what I thought about typing but was too lazy to actually do
This looks really great, i just dont know how to make it work. Is it possible to install the snd-digitakt driver on a working raspbian system or do i have to use the pi-gen tool (which looks really complicated to me)?
I got the
snd-digitakt driver build, installed, and running on my already set up RaspberryPi today. You don’t need to do
pi-gen or rebuild the whole kernel.
It has a lot of steps, but it is very straight forward once I found all the bits… I wrote up a gist with the steps. This was reconstructed from my notes, so there me be some small nits in it… If you try it and you have improvements, let me know and I’ll update it.
Thanks, @droelf - this is truely wonderful and may change my whole live rig…
Thanks @mzero, I linked your gist in the readme of the repo
I hope to find some spare time soon to straighten out things in the driver, having it merged in the mainline kernel surely would be awesome (won’t happen with the current messy and duct-taped version ). In the mean time, anyone who’s willing to enter the exciting world of kernel development is welcome to fill pull requests