[Arch Linux] Very high DIN MIDI latency (USB works fine)

#1

Hey!

I have a very weird issue with my pisound. I’m using with a Raspberry Pi 3 B running Arch and Supercollider (with audio over jack). Long story short I trigger a sampler within a MIDI response function, but there is a good few 100ms of latency (I’m guessing by ear) which is sometimes accompanied by high pitched audio artifacts. This only happens when using the built-in DIN MIDI of the pisound, MIDI over USB works fine as does OSC…

This leads me to think that it might be a hardware or firmware issue. Could you help me figure this one out? I would like to be able to use the built in MIDI as well.

0 Likes

#2

Hi, could you attach the dmesg log when the issue happens?

Is there any way we could try to reproduce the issue on our own? Could you share your patch (we can keep it in private) or could you produce an example patch demonstrating the issue?

Could you try running your patch using Patchbox OS? There’s been a couple of fixes to the Pisound driver a while ago, I don’t know what is the current driver that Arch Linux for Raspbian currently has…

0 Likes

#3

The patch itself has gotten quite out of hand, but the MIDI functionality implemented is very basic. I uploaded it to github for you. The MIDI bits are all the way at the top and bottom. I will try and slim it down to a simpler patch so that you can try to run it yourself (this one does weird file system parsing to find samples to load).

The dmesg I get is linked below. Does this mean the pisound spi transfer is trying to interrupt the kernel? Arch uses the snd_soc_core module as a driver, I could try patchbox os when I have time.

1 Like

#4

This error in dmesg seems to be the cause of the latency. This may be specific to the way the kernel gets built for Arch Linux, I don’t think I’ve seen this exact stack trace and error getting reported in the regular RPi and RPi Real Time kernel configurations. Patchbox OS has the latter integrated.

Please try to reproduce the issue running Patchbox OS when you have time and let us know how it goes!

0 Likes

#5

Yeah using Patchbox solved the issue. No more latency and no dmesg (at least with some test code that only prints out MIDI).

Would it be possible to solve this issue on your side or would that be up to the Arch Linux ARM team? I would like to continue using Arch if it’s possible. Otherwise I guess I’ll have to switch to Patchbox (which seems quite nice actually, but I don’t want/need all the GUI stuff).

0 Likes

#6

You can choose whether to boot to GUI or shell, in the latter case, only the space taken in SD card is impacted, but not the system performance. :slight_smile:

Of course it is possible to get it working fine on Arch Linux one way or another, but we do have limited time to support multiple platforms while continuing development of future products, so Raspbian and Patchbox OS get the most support and stability. :slight_smile: I’ll add fixing this on Arch to my todo, I should be able to get it fixed some time next week. However, at some point in the future, it may break again in some way.

Anyone volunteering to actively support Pisound on Arch Linux would be welcomed! :slight_smile:

0 Likes

#7

Yeah I know, it’s not a deal breaker for me, I just spent quite some time on getting to know Arch. Because a while back supercollider support on Raspbian was a bit lackluster and on Arch it worked out of the box with the latest version.

I wouldn’t mind switching to Patchbox though, the added support (and hopefully stability) kind of outweighs having the latest stuff. Especially since I want this to be part of a live set-up at some point :smiley:

Have you gotten around to fixing it yet? I wouldn’t mind cross-checking my project on Arch for compatibility and helping out with support. I am, however, not that familiar with Linux low level stuff. I would like to get into that as I have plans for designing my own interface that’s eurorack compatible.

0 Likes

#8

Patchbox OS has 3.9.3 version of Supercollider which I think is newer than what was available in “stretch” Raspbian at the time.

Unfortunately no, but I should be able to attempt that towards the end of this week or next week definitely. :slight_smile: I’ll let you know how it goes.

0 Likes

#9

Hey! Ok, I spent some time on this issue today, and submitted a fix for the Pisound kernel module on Raspberry Pi kernel: https://github.com/raspberrypi/linux/pull/3069

Some time next week, a new kernel build should get published, versions exclusively greater than 4.19.57-v7+ should have the fix in them. I think pacman -Syu should be able to install the latest kernel package, once it becomes available for Arch Linux.

0 Likes

#10

Ok, the fix was just merged today, as 4.19.58 is already released, we should expect the fix in versions >= 4.19.59

0 Likes

#11

Nice, I will check it out when I get the chance, was on vacation for a while :slight_smile:

0 Likes

#12

I’ve just updated my Arch setup to linux-raspberrypi-4.19.59-1 and the issue has been resolved. Thanks a bunch!

I’m just curious as to why this was only an issue on Arch, does it have to do with how their build of the kernel handles spinlock?

0 Likes

#13

Yes, Arch Linux seems to have their own kernel builds and the configs to build them, different from the ones used by Raspbian. I don’t know what exact flag causes this difference of behavior, but it seems Arch has some debug check for spinlocks enabled.

0 Likes