[alsa-devel] [PATCH 18/39] firewire-lib: Add a fallback at RCODE_CANCELLED

[Takashi Sakamoto]

Hi Stefan,

 > This 125 ms part of the calculation made me wonder what the split
 > transaction timeout of FCP transactions is (I didn't remember), so I
 > looked it up and wrote down what I found.  So, all of the rest of my
 > reply was not really a direct comment to your patch but merely a loosely
 > related side note.

I think it's not a proper action in this ML...

My intent of this comment is for a notice about time till returining 
from fcp_avc_transaction().
It might be much time against developer's expectation.


 > Correction:  CONTROL or NOTIFY.  (In contrast, STATUS or SPECIFIC INQUIRY
 > or GENERAL INQUIRY commands can only be performed in immediate
 > transactions.  See AV/C v4.2 table 19.  Likewise, already AV/C v1.0 
allows
 > INTERIM response only to CONTROL or NOTIFY commands.)

I confirm my mistake, thanks for your correction ;)


 > I wonder:  Now that firewire-lib's use cases are expanded far beyond 
LaCie
 > Speakers and Griffin FireWave, do we need to implement deferred
 > transactions in firewire-lib too?

Yes. I confirmed some devices use deffered transaction for AV/C CONTROL 
request.
But I still pending this issue, because of the way to handle the 
'unspecified interval'.

I plan to solve this issue for my future work.
This series of patch is the most I can do, now.


 > A related question:  Since FFADO applies 200 ms or more as FCP 
transaction
 > timeout, shouldn't firewire-lib's fcp.c increase FCP_TIMEOUT_MS from 125
 > to 200 or more as well?

For this developing, I've spent much time with my test devices.
But I've never experienced disadvantages under FCP_TIMEOUT_MS=125msec.
So feel no importance.

If you feel this importance, please post your patch with proper reasons.


 > This is about case b) and, now that I think about it, also about case a)
 > in my list further above.

The case a) is for ctype=reserved. Current ALSA Firewire drivers don't 
utilize it.
So I have never considered about this case.

For the case b), I'm optimistic because current fcp_avc_transaction() 
don't return
till the first AV/C response comes (or AV/C request is error). This 
means that
the driver basically don't send any AV/C transaction at the same time.

Furthermore, my drivers basically generate some AV/C transaction in driver's
probe/remove state or starting/stopping playback/capture of PCM samples/MIDI
messages. So I believe that FFADO/ALSA rarely transfer some AV/C 
transactions
at the same time.

In these reasons, I'm optimistic for device's ignorance of AV/C request.

Anyway, I appreciate your advices. Thank you to spend time for my 
developing.


Takashi Sakamoto
o-takashi at sakamocchi.jp