[alsa-devel] [RFC] [PATCH] firewire-lib: add support for AV/C deferred transaction
Clemens and Stefan,
Can I request your comments about attached patch?
This is for adding support of deferred transaction into snd-firewire-lib. I confirm some BeBoB devices use this type of transaction. If you have no negative comments, I'll add this patch for my series.
For 'undefined interval' between INTERIM and final response, I want to use 'FCP_TIMEOUT_MS' (=125msec) again. In specifications which I can read, there is no limit for this interval. But I need to promise to finish this function for callers.
According to AV/C general specification, targets can send INTERIM response one time. But this patch allows to accept several ITERIM responses for device quirks. I don't have devices which have such quirks, but there may be such devices and I want to make codes simpler.
Regards
Takashi Sakamoto o-takashi@sakamocchi.jp
Takashi Sakamoto wrote:
Can I request your comments about attached patch?
This is for adding support of deferred transaction into snd-firewire-lib. I confirm some BeBoB devices use this type of transaction. If you have no negative comments, I'll add this patch for my series.
Looks OK.
For 'undefined interval' between INTERIM and final response, I want to use 'FCP_TIMEOUT_MS' (=125msec) again. In specifications which I can read, there is no limit for this interval. But I need to promise to finish this function for callers.
In theory, a device that uses INTERIM is likely to need a larger timeout than the FCP default, but as long as 125 ms works for those BeBoB devices, increasing the timeout is not necessary.
Regards, Clemens
Hi Clemens,
(Mar 15 2014 07:24), Clemens Ladisch wrote:
Looks OK.
Thanks for your quick review.
In theory, a device that uses INTERIM is likely to need a larger timeout than the FCP default, but as long as 125 ms works for those BeBoB devices, increasing the timeout is not necessary.
With this value and BeBoB devices which I own, I have experienced no retry/timeout.
As long as I know, BeBoB based devices need much time to complete immediate/deferred transaction for changing sampling rate during streaming. In this case, immediate transactions need 150 msec or more and deferred transactions need 40/240msec or more to complete. But BeBoB driver must not change sampling rate in this case because sampling rate should not be changed during streaming. The driver should stop streaming once then change sampling rate.
I suggest that we will change this value when finding devices which need more timeout.
Thanks
Takashi Sakamoto o-takashi@sakamocchi.jp
participants (2)
-
Clemens Ladisch -
Takashi Sakamoto