[alsa-devel] [FFADO-devel] [RFC][PATCH 06/37] ALSA: firewire-lib: add throttle for MIDI data rate
Jonathan Woithe
jwoithe at just42.net
Sun Jul 12 10:31:27 CEST 2015
Hi again Takashi
On Sat, Jul 11, 2015 at 11:12:17PM +0900, Takashi Sakamoto wrote:
> Typically, the target devices has internal buffer to adjust output of
> received MIDI messages for MIDI serial bus. The capacity of the buffer
> is limited, while IEEE 1394 transactions can transfer more MIDI messages
> than MIDI serial bus can. For this reason, the MIDI transmission rate
> should be constrained.
It is good that the core has rate throttling. I haven't looked at the code
in enough detail but it is important for MOTU devices that it is possible to
make the throttling code do the right thing on the assumption that the
firewire device does not actually have a buffer at all. Experiments done in
the past have shown that at least some MOTU models are not able to cope with
MIDI data that is sent any faster than the literal line rate of 31250 bps.
That is, if the bytes of even a single MIDI message are sent faster than
31250 bps then the MIDI bitstream output by the device will be corrupted due
to the dropping of one or more bytes from the message (or other random
creative changes to the data bytes).
In other words, it will need to be possible to tell the throttling code that
the buffer size in the device is 1 byte long and have the code only send to
the MOTU at 31250 bps. MOTUs cannot be assumed to have any internal buffer
for MIDI bytes.
Obviously software is very likely to send MIDI bytes faster than 31250 bps,
so in the FFADO MOTU MIDI code I needed to implement a short circular buffer
in FFADO in order to match these two rates. In FFADO this buffer is sized
at 2^10 bytes and this seems to work reliably: so long as the average rate
sent by software stays below 31250 bps, everything is ok. The relatively
large size is required in order to deal with sysex messages. I imagine it
will be necessary to provide similar functionality in this implementation of
that driver in ALSA.
Regards
jonathan
More information about the Alsa-devel
mailing list