Stefan,
At first, I introduce this is for a patch below. You can see actual logs: [alsa-devel] [PATCH 39/39] bebob: Add support for M-Audio special Firewire series http://mailman.alsa-project.org/pipermail/alsa-devel/2014-February/073484.ht...
It's 2000 ms actually.
Oops. Here I made a mistake to refer to unrelated value here. I might consider about the other thing when writing this commit, perhaps because of noon in Friday and a bit tired...
Well, yes. It's 2000 msec.
(Feb 28 2014 12:27), Takashi Sakamoto wrote:
As a result, in worst case that all of three retries are timeout and devices don't send responses, fcp_avc_transaction() returns 1sec later ((200 + 125) msec * 3 times).
So in this case, this function returns 6,375msec later. (but it's rare, again.)
And this is the IEEE 1394 split transaction timeout of course. FCP transactions on the other hand are transported by means of two IEEE 1394 transactions: One in which the FCP requester is IEEE 1394 requester, and another one in which the FCP responder is IEEE 1394 requester.
firewire-core's split transaction timeout is only relevant to the request subaction of an FCP transaction (i.e. the first one of the two IEEE 1394 transaction),
OK.
and only if this one is being performed as a split transaction rather than a unified transaction, which depends on the FCP responder hardware. (I am not aware of any hardware which handles FCP request subactions as unified transactions.)
As You explained in this message: [alsa-devel] Echo Fireworks control protocol (was Re: Sample program for hwdep interface) http://mailman.alsa-project.org/pipermail/alsa-devel/2014-February/071978.ht...
IEC 61883-1 does not specify any FCP transaction timeout.
I've confirmed it.
The 1394 TA document "AV/C Digital Interface Command Set, Rev. 1.0, 1996" defines FCP transactions (for use with AV/C command set) much more precisely than IEC 61883-1 does:
To each FCP request, there may be 0..n FCP responses.
An AV/C target may emit a final response (one with response code < 0xf) up to 100 ms after reception of an FCP request.
Or the AV/C target may emit an intermediate response (one with response code 0xf for interim response) up to 100 ms after reception of an FCP request. The target shall emit no additional interim response in this transaction, but one final response. There is no timeout specified for this final-after-interim response, i.e. it may take an undefined, possibly very long time. (The AV/C specification v4.0, 2001 adds that subunit specifications may define such timeouts for certain commands.)
Or the AV/C target may still be busy processing a previous command. In this case, the specification accepts that the target does not send any response to subsequent requests at all until it is done with the previous work. The requester may the retry such a failed request after the mentioned 100 ms timeout. (Plus IEEE 1394 transport overhead, but the AV/C specification v1.0 does not mention this. AV/C v4.0 explains that the requester should take certain transport dependent delays into account in addition to the 100 ms FCP timeout, e.g. physical layer repeater delays, or busy retry delays. Furthermore, AV/C v4.0 recommends that a busy target returns certain acknowledge codes or response codes to pipelined requests that exceed its capacity to handle concurrent FCP transactions.)
An "IEEE 1394.0 reset" (sic) terminates any outstanding FCP transaction. (I suppose a 1394 bus reset is meant by this. AV/C v4.0 clarifies this to be an IEEE 1394 bus reset indeed.)
Additionally, there are two types of AV/C transactions, 'immediate transaction' and 'deffered transaction'. Current 'firewire-lib' don't implement 'deffered transaction' so fcp_avc_transaction() always returns first AV/C response frame. This will be response=INTERIM against ctype=STATUS/NOTIFY. The gap between a first response and a second response of 'deffered transaction' is defined as 'unspecified interval'.
But this is not related to an issue about which this patch mentions.
(Mar 01 2014 05:39), Stefan Richter wrote:
To be more precise: The specification accepts that the target*ignores* incoming AV/C command frames while processing an AV/C command. This is indicated to the requester by lack of a response to any ignored request.
To me, this implies that the target must send a response to any request that it did not ignore, i.e. to any command that it executed. On the other hand, I don't think there is any rollback behavior specified or practical in cases when the target is unable to deliver a response to the initiator.
From a quick glance, the FCP transaction specification looks unchanged
from AV/C 4.0, 2001 to v4.1, 2001 and to v4.2, 2004.
I cannot find some sections about such ignorance in 'AV/C Digital Interface Command Set General Specification Version 4.2 (Sep 01, 2004, 1394TA)' and 'IEC 61883-1 ed2'.
Can I request you any pointers about this ignorance?
Thanks
Takashi Sakamoto o-takashi@sakamocchi.jp