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@sakamocchi.jp