Re: Help requested: new HSS1394 MIDI back-end

[Clemens Ladisch <clemens@ladisch.de>]

Sean M. Pappalardo - D.J. Pegasus wrote:
> On 05/31/2012 10:00 PM, Clemens Ladisch wrote:
>> I wrote:
>>> 00 F9 xx yy zz ->  F0 00 01 60 48 53 53 00 00 0F 09 0x 0x 0y 0y 0z 0z F7
>
> This appears to work fine. But where did you get the leading 00 from?

This is how the FireWire packets are constructed.  The first byte is
a tag; 00 means that the rest of the packet contains MIDI data, ...

>>> 13 xx yy zz<- F0 00 01 60 48 53 53 01 03 0x 0x 0y 0y 0z 0z F7
>>> 14 xx yy zz<- F0 00 01 60 48 53 53 01 04 0x 0x 0y 0y 0z 0z F7
>>> (0x13 = 0x10 + 3 = kUserTagBase + uUserTag)

... while tags in the range 10..EF are "user tags".

When you use this function:

> // uUserTag is valid in the range 0x00 - 0xDF.
> virtual uint SendUserControl(uint8 uUserTag, const uint8 *pUserData,
>                              uint uDataBytes) = 0;

libhss1394 will add 0x10 to the tag.

> I just modified Mixxx's SCS.1d script to work with your custom sysex
> messages and tested with your latest patch. The .1d doesn't actually
> work 100% with this since Mixxx never receives some of the standard
> MIDI messages amid all of the sysex ones, and it's much worse when the
> platter is spinning and sending the tons of messages it does. This
> could be due to PortMIDI's lack of a callback mechanism, forcing Mixxx
> to poll it every 1ms because it's much more difficult to reproduce the
> problem using amidi -d.

That's possible.  However, at 4 KB, ALSA's buffer should be big enough
for those messages.

> I also see an F9 message slip through once in awhile according to amidi -d:
> F9
>    55
> 91
> C4

The driver currently assumes that there is exactly one MIDI message per
packet.  It appears that this is not true, and if F9 and real MIDI
commands are mixed in one packet, the result is not correct.

> As soon as I start the JACK server to handle the audio interface on
> the SCS.1m, the ALSA driver stops sending MIDI for that device unless
> I stop JACK and power-cycle the device. Its last words are:
> F0 00 01 60 48 53 53 0F 03 00 03 00 00 0B 01 F7

This is a ping response (tag F3).  Apparently, Jack's FFADO driver
reinitializes the device and registers its own address for received
packets.  Since it does _not_ handle MIDI messages, it really should
not do this.


Regards,
Clemens