one direction performance problem

Submitted by mvo on #1

Hi,

I'm running a purchased virtual here usb server on a raspberry pi (B+) with two midi devices attached (that basically form a user interface with buttons, faders, leds and so on).

It works in principle but there is a huge latency introduced if I send a lot of data towards the device (host -> rpi -> device). The CPU usage for the vhusbdarm process then rises up to 50-65% and the output is delayed by (sometimes) seconds until all data its completly processed.

However, there a two interesting things:

  1. Please note that "a lot of data" should not mean that much as there are only midi messages beeing sent. I don't know how much overhead is added by the usb driver but in general a midi message is only 3 bytes long and I usually send a maximum of ~64 messages at once to set some led states.
  2. If I produce a lot of data at the device (device -> rpi -> host), e.g. by quickly moving multiple faders at once (which outputs a midimessage for every detected little change in position of each fader), everything is fine.

I know the raspberry pi is not a powerful device. But if other people can manage to stream audio this really should work. What is the cpu intensive task in this case? Is decompressing the packages way more expensive that compressing or is there something else going on?

Any help appreciated!

Cheers
Moritz

Submitted by mvo on Tue, 2016/05/24 - 04:28

#3

I am already using the following version which should be the right one for the rpi b+:
vhusbdarmpi (arm1176jzf-s hardware floating point)

Submitted by Michael on Tue, 2016/05/24 - 10:40

#4

yes that is the right one, if the cpu usage is still too high then i think you may need to try a faster pi, like the pi3 as that is quad core and 1.2Ghz and armv7.

If the data packets are less than 384 bytes then compressing is not used. Im not sure of the protocol it is using on top of usb, its unusual to have high cpu usage with just midi transfers so i think perhaps it is using some other protocol which is more complicated and therefore requires more cpu usage to be translated into TCP

Submitted by mvo on Tue, 2016/05/24 - 21:34

#5

I did perform another test:

I created a python script using the Mido/Portmidi libraries to directly access the midi devices. With only a simple listener to incoming midi data (that would directly transfer the 3 byte long packages via a udp socket) and another one listening to another udp socket for remote data (forwarding the data to the midi devices) a similar problem shows up: I get a very high cpu load that introduces latency.

I feel that the problem therefore lies deeper in the system either on the usb or the ethernet side. Mhh, I'm not really shure where to start searching. It's a pretty out of the box raspbian jessie.

Submitted by Michael on Wed, 2016/05/25 - 10:00

#6

Also dont forget that with the pi, the actual ethernet adapter is shared on the same bus as the USB ports. So everything goes though one port