Polyphonic patches chord playing gives stuck notes via USB midi


#1

Hi there,
playing chords with my M-Audio Keystation Mini 32 the polyphonic pathces like i.e. "organ" o "strings" from the ../library/demos/synth, I often obtain random stuck-notes.
In this way I find that the poliphonic patches are quite unusable for a live modality.

Any other similar experience?

Windows 7 x64
CPU i7
Ram 16gb
laptop
USB3 or USB2 connection between Axoloti and the PC
Axoloti 1.0.5


#2

will investigate....


#3

@erminardi , this is with your Mini 32 attached directly to the Axoloti core? or are going via the PC?

anyway, I had to do some testing with my Virus TI (directly to the axoloti board) anyway, so I thought I try this out.

I had no issue with any patch EXCEPT organ..... (strings was fine)
I tried lots of rapid notes and chords etc, and all seemed to be fine.

however with "organ" I found id get stuck notes, especially if playing notes rapidly,
I tried chords on this and other patches and didn't seem to find this caused any issue
I also tried legato vs staccato but couldn't really see a correlation.

so the question is why this patch and not others...

well organ is taking a lot of cpu, ~ 89% so perhaps this is the issue.
but when I increased the strings voices to 10, this took it up to ~84% and this had no issue.
knocking the voices down on organ also seemed to make it stop hanging.

I will say sometimes it hangs quickly other time takes a bit of time so tricky to be 100% sure if reducing voices solved the issue etc.... all i can say is this is what appears to happen.

of course different usb devices have different buffer sizes so this could also play an influential role.

perhaps high cpu causes the midi messages not to be read frequently enough, this could be being aggravated by the fact we are processing the midi in messages within the midi "thread"

anyway just some thoughts/observations... as I had to test something else anyway :smile:


#4

seems to relate to high cpu load indeed, but not sure yet why this drops data.


#5

Thanks to all, I will check ASAP, but I think that the M-Audio has some issues with USB buffer size in Axoloti for poly patches.


#6

High CPU load on the board, not on your PC.

I have found a solution: increasing the priority of the usb host handling in the firmware so it gets a higher priority than audio handling. Needs a bit further testing before making it into a release. Stay tuned!


#7

hmm, guess we need to be careful then that high USB loads (e.g. linnstrument) don't lead to audio glitches.

the other thing that crossed my mind, was the decoupling of the usb reading/midi parsing, to delivery of the midi message to the control rate handler (lets call this midi handling)
perhaps because the this usb thread is also do the midi message handling, its taking longer than it should...
we talked before about a message queue to avoid this (and also alleviate our concerns over the possible threading issues caused by this)

@erminardi axoloti should be reporting the USB buffer size in the console for the device. what is it reporting?
(there is a max size in the firmware, but I don't think you will be hitting it)


#8

Hi @thetechnobear Mark, helping hand here;

I did try yesterday really quick using the AXIS49 an yep stuck notes - patch:organ…

Does this help?

Axoloti says: USB Host : device disconnected
Axoloti says: USB Device Attached
Axoloti says: PID: 1h
Axoloti says: VID: 1D17h
Axoloti says: Address (#1) assigned.
Axoloti says: Manufacturer : C-Thru Music Ltd
Axoloti says: Product : AXIS-49 2A
Axoloti says: Serial Number : CTMAX49 00.00.13
Axoloti says: Enumeration done.
Axoloti says: This device has only 1 configuration.
Axoloti says: Default configuration set.
Axoloti says: Switching to Interface (#0)
Axoloti says: Class : 1h
Axoloti says: SubClass : 3h
Axoloti says: Protocol : 0h
Axoloti says: USB Host Output size requests : 40
Axoloti says: USB Host Output interval : 0
Axoloti says: USB Host Input size requests : 40
Axoloti says: USB Host Input interval : 0
Axoloti says: USB Host Output connected to 0 : 1
Axoloti says: USB Host Input connected to 0 : 81
Axoloti says: MID class started.


#9

I'll be glad to test things with my linnstrument !


#10

I think an audio glitch is preferred over lost midi data.

USB host processor load should be minimized, I see a lot of wrapper functions that do not get inlined.
Like USBH_BulkReceiveData -> USBH_LL_SubmitURB -> HAL_HCD_HC_SubmitRequest
This requires enabling link time optimisation in firmware, or macro-izing some functions. Or maybe the USBHS peripheral has tricks available that the STM usb host lib does not use.


#11

I just recently got my axoloti, and I'm running into the same problem with an Akai MPK mini. I replicated it with the default "organ" patch. Even when setting polyphony to "1" it is the same. I try to describe some observations I made:

  • I observed that when using the "live" mode, everything works fine as it should, but when I send it to flash and reboot the axoloti, then the notes will hang.
  • When just using a subpatch alone without polyphony it works fine. As soon as I add that subpatch to a new patch with polyphony (even just 1 voice) it will hang.
  • It seems that the only the "note-off" messages are not received or processed: I mapped some parameters to the knobs of my keyboard and they all work fine. You can also notice that if you play a chord, and then just press one key repeatedly, all other notes will stop due to last-note-priority.

The original post was from 5 years ago, has anyone found a solution since in the meantime?

I had hoped to use the axoloti as a portable standalone synth with this keyboard, as it is one of the few that has an usb host functionality.


#12

@johannes, @thetechnobear I also just checked, I don't think a high cpu load has anything to do with it. I just did a simple patch with midi-in, adsr, sine-oscillator, vca and stereo-out, as soon as you set it to polyphonic it will hang, even though the load of the subpatch alone is displayed as 0% or 1%.


#13

Related to this maybe?


#14

Thanks a lot for the link, I just tried it and it seems that plugging in a 1/4 to 3.5mm into the sustain pedal input "solves" the issue!