OB for Linux (sorta ;)

Nevets · February 4, 2019, 2:37pm

A good example of this might be Elektron removing CC 93 (solo) from the Digitakt firmware. I guess they did it to prevent people from soloing a track with a controller and no way on the machine to undo that. Too bad though, it was fun to have.

Nevets · February 4, 2019, 2:51pm

Same error with a board running a 4.x kernel. The first try was running 5.x kernel. I guess it has something to do with this piece of code, but I really have no idea how to fix it. Any clues would be appreciated

static void sighandler(int s){
        printf("Shutting down ...\n",s);
        shtdwn = 1;
}

int main(int argc, char *argv[]) {

        // sighandler setup
        struct sigaction sigIntHandler;
        sigIntHandler.sa_handler = sighandler;
        sigemptyset(&sigIntHandler.sa_mask);
        sigIntHandler.sa_flags = 0;
        sigaction(SIGINT, &sigIntHandler, NULL);

Hans_Olo · February 4, 2019, 2:56pm

Just a wild guess without any context and possibly with other unwanted side effects. Maybe try replacing line

printf(“Shutting down …\n”,s);

with

printf(“Shutting down …\n”);

Nevets · February 4, 2019, 2:58pm

Different errors but same result. Maybe it’s only meant to be build on x86?

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:302:9: error: stray ‘\342’ in program
  printf(???Shutting down …\n”);
         ^
/root/dtdump/dtdump.c:302:10: error: stray ‘\200’ in program
  printf(???Shutting down …\n”);
          ^
/root/dtdump/dtdump.c:302:11: error: stray ‘\234’ in program
  printf(??Shutting down …\n”);
           ^
/root/dtdump/dtdump.c:302:12: error: ‘Shutting’ undeclared (first use in this function)
  printf(“Shutting down …\n”);
            ^~~~~~~~
/root/dtdump/dtdump.c:302:12: note: each undeclared identifier is reported only once for each function it appears in
/root/dtdump/dtdump.c:302:21: error: expected ‘)’ before ‘down’
  printf(“Shutting down …\n”);
                     ^~~~
/root/dtdump/dtdump.c:302:26: error: stray ‘\342’ in program
  printf(“Shutting down ???\n”);
                          ^
/root/dtdump/dtdump.c:302:27: error: stray ‘\200’ in program
  printf(“Shutting down ???\n”);
                           ^
/root/dtdump/dtdump.c:302:28: error: stray ‘\246’ in program
  printf(“Shutting down ??\n”);
                            ^
/root/dtdump/dtdump.c:302:29: error: stray ‘\’ in program
  printf(“Shutting down …\n”);
                             ^
/root/dtdump/dtdump.c:302:31: error: stray ‘\342’ in program
  printf(“Shutting down …\n???);
                               ^
/root/dtdump/dtdump.c:302:32: error: stray ‘\200’ in program
  printf(“Shutting down …\n???);
                                ^
/root/dtdump/dtdump.c:302:33: error: stray ‘\235’ in program
  printf(“Shutting down …\n??);                                     ^

CMakeFiles/dtdump.dir/build.make:62: recipe for target 'CMakeFiles/dtdump.dir/dtdump.c.o' failed
make[2]: *** [CMakeFiles/dtdump.dir/dtdump.c.o] 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

Funny if I replace the quotations from “ to " the error goes away but the build still fails.

Scanning dependencies of target dtdump
[ 50%] Building C object CMakeFiles/dtdump.dir/dtdump.c.o
[100%] Linking C executable dtdump
CMakeFiles/dtdump.dir/dtdump.c.o: In function `prepare_transfers':
dtdump.c:(.text+0x52): undefined reference to `libusb_alloc_transfer'
dtdump.c:(.text+0x70): undefined reference to `libusb_alloc_transfer'
CMakeFiles/dtdump.dir/dtdump.c.o: In function `free_transfers':
dtdump.c:(.text+0xb0): undefined reference to `libusb_free_transfer'
dtdump.c:(.text+0xbc): undefined reference to `libusb_free_transfer'
CMakeFiles/dtdump.dir/dtdump.c.o: In function `digitakt_init':
dtdump.c:(.text+0x170): undefined reference to `libusb_set_configuration'
dtdump.c:(.text+0x190): undefined reference to `libusb_set_configuration'
dtdump.c:(.text+0x1b0): undefined reference to `libusb_claim_interface'
dtdump.c:(.text+0x1d0): undefined reference to `libusb_claim_interface'
dtdump.c:(.text+0x1f2): undefined reference to `libusb_set_interface_alt_setting'
dtdump.c:(.text+0x214): undefined reference to `libusb_set_interface_alt_setting'
dtdump.c:(.text+0x234): undefined reference to `libusb_clear_halt'
dtdump.c:(.text+0x254): undefined reference to `libusb_clear_halt'
CMakeFiles/dtdump.dir/dtdump.c.o: In function `usb_shutdown':
dtdump.c:(.text+0x2d2): undefined reference to `libusb_close'
dtdump.c:(.text+0x2dc): undefined reference to `libusb_exit'
CMakeFiles/dtdump.dir/dtdump.c.o: In function `prepare_cycle':
dtdump.c:(.text+0x40a): undefined reference to `libusb_submit_transfer'
dtdump.c:(.text+0x422): undefined reference to `libusb_submit_transfer'
CMakeFiles/dtdump.dir/dtdump.c.o: In function `main':
dtdump.c:(.text+0x4d8): undefined reference to `libusb_init'
dtdump.c:(.text+0x58e): undefined reference to `libusb_open_device_with_vid_pid'
dtdump.c:(.text+0x5f0): 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

One step further anyways, thanks for the pointer!

tnussb · February 4, 2019, 3:37pm

The first 2 errors were simple. An unnessary parameter to printf and then a wrong character used as ASCII double-quote.

Now it compiles but fails linking, because it cannot find functions from library libusb.

The README.md states:

needs …, libusb, libsndfile, …

Have you installed these libs?

PS: there is nothing in the sourcecode that is bound to x86, so it should run on any modern linux platform.

Nevets · February 4, 2019, 3:54pm

Yeah I have those libs and their -dev versions installed. It does find them too when running the “cmake …/” command.

I’m running Debian for arm on this board. It’s just plain Debian.

root@aml:~/dtdump/build# dpkg-query -l | grep usb
ii  libusb-0.1-4:arm64              2:0.1.12-31                        arm64        userspace USB programming library
ii  libusb-1.0-0:arm64              2:1.0.21-2                         arm64        userspace USB programming library
ii  libusb-1.0-0-dev:arm64          2:1.0.21-2                         arm64        userspace USB programming library development files
ii  libusb-1.0-doc                  2:1.0.21-2                         all          documentation for userspace USB programming
ii  libusb-dev                      2:0.1.12-31                        arm64        userspace USB programming library development files
ii  usbutils                        1:007-4build1                      arm64        Linux USB utilities

I thought maybe those 1.0 and 0.1.x versions of libusb could conflict but they’re both needed. The other dependancy libsndfile is also installed, both normal and -dev package.

tnussb · February 4, 2019, 4:12pm

Well, it’s clearly the linker complaining. I’ve had a quick check (for at least the first missing function) if there is a version conflict, but the versions seems okay (matching function signatures). The makefile seems okay, too. It would stop if there is no libusb, before reaching the linker part.

Without setting up the stuff myself (sorry, no time for this now), I don’t see what’s wrong.

I think you’ll need to wait for @droelf to help you out on this.

Nevets · February 4, 2019, 4:15pm

Thanks for helping thought. I doubt the arm boards are powerful enough to capture all tracks but recording the master pair shouldn’t be a problem. Hope it can be compiled on arm so I can make a fun sized portable digital Digitakt recorder

tnussb · February 4, 2019, 4:20pm

I don’t see why the arm boards shouldn’t be powerful enough. It’s just a stream of 10MB/s with almost no processing involved. I’ve done already more number crunching on a RaspberryPi and similar devices.

The limiting factor is only the speed of the storage device (as the original author stated, too).

Nevets · February 4, 2019, 4:24pm

I missed that part, even better!

I think the cc command fails as it needs to be adapted to maybe include the correct paths or something. Too bad my knowledge pretty much ends at fixing libs and dependancies for compiling code.

cc -rdynamic CMakeFiles/dtdump.dir/dtdump.c.o -o dtdump -lusb -lsndfile

droelf · February 4, 2019, 4:32pm

Please excuse the messy code. Yes, it was only tested on x64. I’ll investigate later after work.

t · February 4, 2019, 4:49pm

The tracks are being sent out by much slower ARM cores, so I guess without too much OS overhead and a fast board it should be possible.

Nevets · February 4, 2019, 5:04pm

There’s no overhead from the OS I think. Clean Debian install is pretty clean, not many deamons running. My dev boards have Mali 450, 1GB ram, 8gb emcc and quad core Cortex A53 @ 1.5ghz. Can be overclocked to 2ghz but then it needs a noisy fan. The storage is slim but they’re lovely little boards.

tnussb · February 4, 2019, 5:18pm

The Digitakt uses a single-core Freescale Coldfire microprocessor (MCF54418x) which isn’t ARM-based, but more like the m68k processors. And, yes, much slower. It runs @ 250MHz.

BTW: the Digitone uses two of these and a Xilinx Spartan FPGA to coordinate them.

Nevets · February 4, 2019, 5:21pm

Did you see the (debug?) header on the board of the Digitakt? Wonder what kind of (fun) stuff can be done with the board

digiboard

t · February 4, 2019, 5:41pm

Yes, sorry. I actually knew that.

droelf · February 4, 2019, 7:31pm

I just reformatted the code and removed the string parameter. Also, added some info to the README, about the audio routing settings.

Nevets · February 4, 2019, 8:06pm

You fixed it
It compiles fine now. Will let you know how it performs once I get the chance to hook up the Digitakt. Thanks again for sharing this.

root@aml:~/dtdump/build# cmake ../
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found LIBSNDFILE: /usr/lib/aarch64-linux-gnu/libsndfile.so
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Checking for module 'libusb-1.0'
-- Found libusb-1.0, version 1.0.21
-- Looking for libusb_get_device_list in /usr/lib/aarch64-linux-gnu/libusb-1.0.so
-- Looking for libusb_get_device_list in /usr/lib/aarch64-linux-gnu/libusb-1.0.so - found
-- 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-1.0.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
[100%] Linking C executable dtdump
[100%] Built target dtdump
root@aml:~/dtdump/build# ./dtdump
No Digitakt found!
root@aml:~/dtdump/build#

Nevets · February 4, 2019, 10:25pm

I did some testing, seem to work ok but it also lost a few minutes of recording. Was just recording some of the demo patterns and switching between them for a few minutes.

The finished recording was about 35 seconds long and 80mb. Ableton of course can’t open these multi track wav files but Audacity can, or maybe a bit. Not sure where or what goes wrong but this is a great start.

My little arm board didn’t seem to struggle at all. I will do some more and better testing tomorrow.

droelf · February 4, 2019, 10:35pm

… and I just discovered a race condition while testing on a raspberry, which stops the transfer after a couple of seconds, at least on my rpi. But I guess I know what to fix, you don’t see those issues on beefy desktop PCs. Also, going to move the disk writing to a separate process or thread. Thanks @Nevets, looks like you’re the first getting this to (at least) partially work, so people can see I’m not trolling Btw. played/imported the 12 track WAVs in Ardour (open source DAW).