[alsa-devel] [PATCH 18/39] firewire-lib: Add a fallback at RCODE_CANCELLED
o-takashi at sakamocchi.jp
Sat Mar 1 04:18:19 CET 2014
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
> 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,
> 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
> 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
> 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
>>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?
o-takashi at sakamocchi.jp
More information about the Alsa-devel