[alsa-devel] Sample program for hwdep interface

[Takashi Sakamoto]

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.html

Regards


Takashi Sakamoto