Jonathan, Clemens,
I'm sorry to be late for reply but I need to enjoy my year-end holidays to refresh my brain.
(Dec 21 2013 19:11), Jonathan Woithe wrote:
I thought this ticket was more or less resolved.
I've just added a workaround for this ticket. My patch avoids buffer-over-run/assertion and apply some fallback. Then FFADO just looks to handle the models.
(Dec 21 2013 19:11), Jonathan Woithe wrote:
This ticket requires fixes within FFADO's mixer/control code (or so I
thought).
Yes. And this ticket still affects FFADO's streaming functionality.
(Dec 21 2013 19:11), Jonathan Woithe wrote:
How exactly does this program deal with ticket #360? Or is this program simply demonstrating what FFADO must do?
This program just demonstrates how to use hwdep interface.
For Fireworks, via this interface, FFADO can use all of implemented commands without failures. And it's my solution for this ticket.
Here, I try to describe the detail related to this ticket[1]. I should have mentioned the detail in ffado-devel but I got the whole picture in the end of last year.
Cause: The bug is due to failure of some commands in some models. The commands are 'EfcGetClockCmd' and 'EfcPolledValuesCmd'. These commands are used to get device status. The bug appears in initializing process of FFADO. So this bug affects both streaming and mixer/control functionality.
Workaround: Using alternative way when failed. - 'AV/C PLUG SIGNAL FORMAT' command to get sampling rate (applied at r2240) - 'AV/C SIGNAL SOURCE' command to get clock source (not applied) But disadvantages. - No alternatives for 'EfcPolledValuesCmd' - GenericAVC device class has a bug to switch sampling rate (I'm under further investigation.)
Fact: I actually confirmed these commands are failed in one of reported models. But these commands are success in unreported models. FFADO implementation of these commands is over 'AV/C VENDOR DEPENDENT' command. So I tried these commands via specific addresses which Windows driver uses. Then I got always success in the models.
Information: In the end of last year, I had a contact in Echo Audio. I asked the implementation of 'Echo Fireworks Command/Response' over 'AV/C vendor dependent' command. The person answered that some commands are not implemented on current firmware for reported models. (I have no information for the reason.) The person also said that there are no differences between firmwares installed by drivers of Windows/OS X.
A solution: Using these addresses for command/response.
An issue: Using an address range for response has an issue. The address range is an exclusive-resource in an system [2].
In my opinion, considering ALSA/FFADO, it's better that such resource is used in kernel-land driver and the driver gives an interface to use it for user-land application.
Of cource, there is another way, to use this resource just in one user-land application such as ffado-dbus-server. Then I need to make another way for kernel-land driver. (Maybe implementing alternative AV/C commands)
[1] http://subversion.ffado.org/ticket/360 [2] http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/070447.ht...
Regards
Takashi Sakamoto