Add RtMidi back-end

Registered by Sean M. Pappalardo on 2011-03-05

In discussing scratching performance for MIDI controllers, particularly high-resolution ones (SCS.1d, NS7/V7,) it would be convenient to have a callback-based MIDI back-end (PortMIDI only supports polling.) RtMidi was suggested (http://www.music.mcgill.ca/~gary/rtmidi/) Implement it as an alternate, since the MIDI back-end subsystem is now modular.

Blueprint information

Status:
Started
Approver:
Mixxx Development Team
Priority:
Low
Drafter:
Mixxx Development Team
Direction:
Needs approval
Assignee:
None
Definition:
Discussion
Series goal:
None
Implementation:
Blocked
Milestone target:
None
Started by
Daniel Schürmann on 2013-03-31

Whiteboard

hile from IRC is looking at doing this as part of supporting hot-plugging.

---
Daniel Schürmann:

I have made a short review of the RtMidi code, without additional test. (So maybe I am totaly wrong) Here are my results:

I think RtMidi is not suitable for Mixxx because of the following reasons:

1. The ALSA interface is implemented by a polling thread which is scheduled every ~1 ms. This was identified as too often. (See Bug #990992)
2. The Windows, Mac and Jack interface is actually implemented as a callback routine from an thread initiated with some init functions. I don't know if they are also just polling threads or are waked by the kernel but in any case they will fire in a for Mixxx unpredictable moment. For me it is better to let Mixxx itself control when Midi data should be processed.
3. At least in case of Jack the callback is fired with realtime priority. I do not know if this is the same thread as the audio callback thread, but in general it is enough to have only one periodical RT thread in mixxx. We may achieve the same results, if we do the midi polling within the audio thread. But I dont think this is required because we do not process a audio Midi stream, just Midi control commands.
---
Sean Pappalardo:
Do these still stand for v3.0.0 of RtMidi? There is the option of having input messages queued instead of called back, then we use getMessage() to retrieve them. This eliminates the concern in point #2 at least.
For point #3, real-time priority is desirable for controllers with spinning platters as they send tons of data and any lag causes a warble in playback. The Controller subsystem creates a separate thread for each ControllerEngine.

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.