libusb_set_configuration fails on RPi
Lcchy opened this issue · comments
Hi there, thanks so much for the amazing work! Truly inspiring!
I am trying to run overwitch on my Raspberry Pi 4, the build and installation went smoothly and overbridge -l gives me the expected:
$ overwitch -l
Bus 001 Port 001:002 Device 006: ID 1935:000c Digitakt
But when trying to run it I get:
$ overwitch -d Digitakt -v -v
DEBUG:overbridge.c:534:(overbridge_init_priv): Checking for Digitakt...
Device: Digitakt (outputs: 12, inputs: 2)
ERROR:jclient.c:593:(jclient_run): USB error: can't set usb config
Any help is very welcome
The error seems to come from here
Line 556 in 0059aad
Ps: I should mention that I had already installed the alsa driver from here https://github.com/droelfdroelf/snd-digitakt, could this be interfering with overwitch? I tried to remove the module but I'm unsure that it worked.
Thanks for your kind words.
As everything looks nice, I've just pushed the print_init_error branch that will hopefully help us to fix your issue.
Check it out and let me know what is your output.
Probably, the culprit is the kernel module that has already set the configuration, yet I want to be sure. So, if the above doesn't help, remove the kernel module with sudo modprobe -r snd-digitakt and try again.
Thanks a lot for your answer and the debug branch!
You were right indeed, I didn't remove the kernel module properly as apparently it gets reinserted each time the device is reconnected. I was getting this with the print_init_error branch:
$ overwitch -d Digitakt -v -v
DEBUG:overbridge.c:533:(overbridge_init_priv): Checking for Digitakt...
Device: Digitakt (outputs: 12, inputs: 2)
ERROR:overbridge.c:633:(overbridge_init_priv): Error while initializing device: LIBUSB_ERROR_BUSY
ERROR:jclient.c:593:(jclient_run): USB error: can't set usb config
After removing it and running overwitch directly, I am now getting some very promising outputs, and some sounds!
But it seems that there is some kind of constant distortion going on, kind of like a bitcrusher effect, so I was suspecting some buffer to be too small yet changing the jackd --period to 64 or 512 didn't help and neither did the --nperiod or the overwitch -b.
I don't get any xruns warnings from overwitch or Jack, which is suspicious.
(I run jack with /usr/bin/jackd -R -P 95 -d alsa -d hw:0 -r 48000 --period 128)
My Jack server runs on a RPi with a gpio soundcard board as device. In my use case the audio is generated by the Digitakt, transferred by overwitch to the RPi jack server and then routed back to the Digitakt with overbridge. The distortion actually only appears on the way from the RPi and to the Digitakt via overwitch, it doesn't happen when using the jack server's device output or with overwitch in the other way.
I recorded a sine wave, first using the gpio soundcard output:
Then running it to the Digitakt output via overwitch:
Could there be some kind of buffer reading that is out of sync? I don't know where to look next, any help is most definitely welcome.
The Digitakt has a 24bit output apparently, but it looks like jack handles this by wrapping the values in 32bit.
I think I will try and set up the same routing but using my PC instead of the RPi, and see how it goes
PS: Apart from that the latency seems on point! This is pretty rad
This was what I was expecting and what I changed. Someone else had opened the device.
ERROR:overbridge.c:633:(overbridge_init_priv): Error while initializing device: LIBUSB_ERROR_BUSY
Regarding the distortion, I've just pushed 7668f2c to the same branch to replace the endianness conversion functions. Digitakt is big endian, and so is the RPi, but my PC is x86 (little endian). That's why I think that the issue is there. However, unless there was a rounding endianness error, it will behave likewise.
In case you're interested, JACK handles audio in 32 bits float format by default and, regardless of the Digitakt bit depth, audio thru Overbridge goes as 32 bits integer. A bit complicated but every layer is well defined.
Could you try that commit to see if there is any difference?
This was it! The sound is now completely clean and nice, thanks a lot for your help.
I have one last question, as I am getting some xruns that crash overwitch when trying to find the right buffer size, do you think it would be possible to recover from these errors in order to keep the program running even if the sound is compromised temporarily?
These are the kind of error messages I am getting:
o2j latency: 0.0 ms, max. 0.0 ms; j2o latency: 0.0 ms, max. 0.0 ms; o2j ratio: 0.999992, avg. 1.000263
o2j latency: 0.0 ms, max. 0.0 ms; j2o latency: 0.0 ms, max. 0.0 ms; o2j ratio: 1.000023, avg. 1.000018
o2j latency: 0.0 ms, max. 0.0 ms; j2o latency: 0.0 ms, max. 0.0 ms; o2j ratio: 1.000037, avg. 1.000030
o2j latency: 0.0 ms, max. 0.0 ms; j2o latency: 0.0 ms, max. 0.0 ms; o2j ratio: 1.000052, avg. 1.000045
o2j latency: 0.0 ms, max. 0.0 ms; j2o latency: 0.0 ms, max. 0.0 ms; o2j ratio: 1.000058, avg. 1.000056
o2j latency: 0.0 ms, max. 0.0 ms; j2o latency: 0.0 ms, max. 0.0 ms; o2j ratio: 1.000059, avg. 1.000060
o2j latency: 3.3 ms, max. 5.1 ms; j2o latency: 0.0 ms, max. 0.0 ms; o2j ratio: 1.000051, avg. 1.000054
ERROR:jclient.c:216:(jclient_o2j): o2j: Unexpected frames with ratio -0.400369 (output 0, expected 64)
ERROR:jclient.c:216:(jclient_o2j): o2j: Unexpected frames with ratio -1.196661 (output 0, expected 64)
ERROR:jclient.c:216:(jclient_o2j): o2j: Unexpected frames with ratio -2.189077 (output 0, expected 64)
ERROR:jclient.c:216:(jclient_o2j): o2j: Unexpected frames with ratio -3.376316 (output 0, expected 64)
ERROR:jclient.c:216:(jclient_o2j): o2j: Unexpected frames with ratio -4.555702 (output 0, expected 64)
This was it! The sound is now completely clean and nice, thanks a lot for your help.
Glad it works now. 🚀
Regarding the crashing errors, I'm aware of them. I've been trying to fix it for weeks and I think I've just got it today.
The problem is that under certain conditions, a substraction of unsigned longs was overflowing and hence the negative ratios. Tomorrow I'll test it properly and push more commits to the same branch for you to test it.
If it works, I'll release version 0.2 in the following days.
I've just pushed the commits I talked about yesterday. Hopefully, negative ratios won't happen again.
If possible, I'd like you to try this and even try to break it. It's much more stable now and I only get occasional xruns with 32 frames.
o2j latency: 0.6 ms, max. 2.1 ms; j2o latency: 1.2 ms, max. 1.8 ms; o2j ratio: 0.999893, avg. 0.999892
@Lcchy, you haven't said anything about the crashes. I'm aware that I asked you this only 3 days ago so consider this a gentle but nervous ping as the sooner we close this the sooner I'll be able to release the next version.
If not possible, I'll try next week because it's not really important.