All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: Clemens Ladisch <clemens@ladisch.de>
Cc: tiwai@suse.de, alsa-devel@alsa-project.org, ffado-devel@lists.sf.net
Subject: Re: [PATCH 2/3] fireface: add transaction support
Date: Thu, 10 Dec 2015 20:31:55 +0900	[thread overview]
Message-ID: <566962AB.1060304@sakamocchi.jp> (raw)
In-Reply-To: <5666CEC0.103@ladisch.de>

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

  reply	other threads:[~2015-12-10 11:31 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-06 13:23 [RFC][PATCH 0/3] ALSA: fireface: new driver for RME Fireface series (MIDI only) Takashi Sakamoto
2015-12-06 13:23 ` [PATCH 1/3] fireface: add skeleton for RME Fireface series Takashi Sakamoto
2015-12-06 22:13   ` [FFADO-devel] " Jonathan Woithe
2015-12-07  1:32     ` Takashi Sakamoto
2015-12-07  2:05       ` Jonathan Woithe
2015-12-06 13:23 ` [PATCH 2/3] fireface: add transaction support Takashi Sakamoto
2015-12-08 10:22   ` Clemens Ladisch
2015-12-08 11:25     ` Takashi Sakamoto
2015-12-08 11:29       ` Clemens Ladisch
2015-12-08 12:20         ` Takashi Sakamoto
2015-12-08 12:36           ` Clemens Ladisch
2015-12-10 11:31             ` Takashi Sakamoto [this message]
2015-12-06 13:23 ` [PATCH 3/3] fireface: add support for MIDI functionality Takashi Sakamoto
2015-12-06 14:29 ` [FFADO-devel] [RFC][PATCH 0/3] ALSA: fireface: new driver for RME Fireface series (MIDI only) Илья
2015-12-06 21:57 ` Jonathan Woithe
2015-12-07  1:27   ` Takashi Sakamoto
2015-12-07  1:37     ` Jonathan Woithe
2015-12-07  1:52       ` Takashi Sakamoto
2015-12-07  2:05         ` Takashi Sakamoto
2015-12-07  2:21           ` Jonathan Woithe
2015-12-07  2:42             ` Takashi Sakamoto
2015-12-07  3:01               ` Jonathan Woithe
2015-12-07  7:37             ` Clemens Ladisch
2015-12-07  8:41               ` Jonathan Woithe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=566962AB.1060304@sakamocchi.jp \
    --to=o-takashi@sakamocchi.jp \
    --cc=alsa-devel@alsa-project.org \
    --cc=clemens@ladisch.de \
    --cc=ffado-devel@lists.sf.net \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.