Re: [Jack-Devel] CoreMIDI driver bug fix

Le 3 mars 2013 à 23:46, Devin Anderson <[hidden]> a écrit :

> Hi Christian,
> 
> On Sun, Mar 3, 2013 at 2:39 PM, Christian Schoenebeck
> <[hidden]> wrote:
>> On Saturday 02 March 2013 20:29:53 Devin Anderson wrote:
>>> That's interesting.  The iOS CoreMIDI spec says the same thing as the
>>> MacOSX CoreMIDI spec.  Is that MIDI coming from the hardware driver,
>>> or from other CoreMIDI applications?  Has a bug been filed against
>>> either CoreMIDI or whatever is sending the MIDI messages?
>> 
>> It sais the same, because like many APIs in iOS, the CoreMIDI API seems to be
>> copied by Apple as it is. In many iOS API docs you find things like
>> "Availability: Available in OS X v10.5 and later" - full stop, not even
>> mentioning any iOS version at all.
>> 
>> The issue with "running status" seems to be emitted by the iOS hardware
>> driver. I never encountered it myself, since I don't have a keyboard or MIDI
>> controller which sends with running status ATM. I'm trusting here on couple
>> end users who reported this "running status" issue to exist on iOS. And in
>> fact there were some other end users who reported exactly these symptoms on
>> iOS (numerous dropped note on / off events). The reported keyboards (I still
>> find in my mails) which would have that issue were: Alesis 49, some Novation
>> keyboard and "maybe" Akai synth station (not sure about the latter). These
>> were all end user reports. Hardware defects can be exluded, since the users
>> reported those keyboards to work with other, more mature CoreMIDI iOS apps.
>> 
>> I haven't filed a bug at Apple's bug tracker system, nor checked if there is
>> one already. So far I haven't even proofed that this bug really exists.
> 
> Perhaps the numerous dropped note-on/note-off events are due to the
> multiple message/packet bug, and have nothing to do with running
> status.  I can't confirm the possibility either way, as I don't have
> access to a Mac or an iPhone.
> 
>> I just pushed some temporary code for handling multiple events in one
>> MIDIPacket. Maybe Stéphane can merge it to the official git server again.
>> It's quite some amount of code now. It could be reduced to only few lines, by
>> splitting JackCoreMidiInputPort::ProcessCoreMidi() into 2 methods (one method
>> only iterating over events, calling each time the 2nd method which is
>> guaranteed to receive only data of exactly one event). However I think it's
>> not worth it at this point, since I expect the whole MIDI parser code in
>> JackCoreMidiInputPort to be dropped in favor of using
>> JackMidiRawInputWriteQueue very soon.
> 
> Excellent. :)
> 
>>> If you plan on adding the JackMidiRawInputWriteQueue, then I'd like to
>>> make a suggestion.  The alsarawmidi driver and the FFADO driver use
>>> the JackMidiRawInputWriteQueue.  If you need a reference on how to use
>>> the driver, you can look at those drivers.  The alsarawmidi driver is
>>> probably more relevant because it uses the two thread scheme to handle
>>> MIDI messages, just like CoreMIDI.
>> 
>> Ok, I try to find a bit of time for that task in probably two weeks.
> 
> Awesome!  When I wrote the code, I didn't have access to a Mac, so I
> couldn't debug (or even compile) what I wrote.  Just a warning, as
> there could be other bugs lurking in the code.
> 
>>> If you have any other questions regarding the MIDI queue system,
>>> please send me a message.  I'm happy to help. :)
>> 
>> Ok, I will get back at that. :)
> 
> :)


Merged on jack2 master here: https://github.com/jackaudio/jack2/commit/023262251e66efda8c1f33e132d67798951626b9

Stéphane

1362375155.4658_0.ltw:2, <570E9AF6-B013-47FF-B244-21013BEB6944 at grame dot fr>