[alsa-devel] [PATCH 2/3] fireface: add transaction support

[Takashi Sakamoto]

On Dec 08 2015 21:36, Clemens Ladisch wrote:
> Takashi Sakamoto wrote:
>> On Dec 08 2015 20:29, Clemens Ladisch wrote:
>>> Takashi Sakamoto wrote:
>>>> On Dec 08 2015 19:22, Clemens Ladisch wrote:
>>>>> Takashi Sakamoto wrote:
>>>>>> +		/* Calculate consume bytes. */
>>>>>> +		consume = calculate_message_bytes(status);
>>>>>> +		if (consume <= 0)
>>>>>> +			return;
>>>>>
>>>>> As far as I can see, sending one of the "undefined" bytes can stop the
>>>>> stream permanently.  Invalid bytes need to be acked to ignore/remove
>>>>> them.
>>>>
>>>> Exactly. We should find better way to handle such messages. Do you have
>>>> any good ideas?
>>>
>>> Call snd_rawmidi_transmit_ack(, 1) and continue.
>>
>> $ git diff
>> diff --git a/sound/firewire/fireface/fireface-transaction.c
>> b/sound/firewire/fireface/fireface-transaction.c
>> index 07a2b9c..6b8c7a8 100644
>> --- a/sound/firewire/fireface/fireface-transaction.c
>> +++ b/sound/firewire/fireface/fireface-transaction.c
>> @@ -148,8 +148,10 @@ static void transmit_midi_msg(struct snd_ff *ff,
>> unsigned int port)
>>
>>                 /* Calculate consume bytes. */
>>                 consume = calculate_message_bytes(status);
>> -               if (consume <= 0)
>> +               if (consume <= 0) {
>> +                       snd_rawmidi_transmit_ack(substream, 1);
>>                         return;
>> +               }
>>
>>                 /* On running-status. */
>>                 if ((*buf & 0x80) != 0x80) {
>>
>> Hm. This looks simple and works better, while I suspect that this is
>> appropriate to device driver, because this idea drops the message from
>> userspace. This is against a principle that device drivers just pass
>> data from a side to another side without censoring and modification.
>>
>> I think it better to transfer the message to the device, even if it's
>> invalid in MIDI spec. It's what the userspace wants.
> 
> The code takes care to send entire MIDI messages.
> Is that actually required by the FF?  (Windows does not have a raw MIDI
> interface, so this problem could not happen there.)

Windows driver performs it so I immitate it.

I confirmed that bytes of one MIDI message in continuous two
asynchronous transactions are handled correctly. So we can purge the
codes for calculation of the number of bytes in the MIDI message.


Thanks

Takashi Sakamoto