[alsa-devel] include/uapi/firewire.h for other firewire drivers

[Takashi Sakamoto]

> When the clock source is internal or the PC, the driver can change
> the sample rate.  When the clock source is external, the rate is
> constrained.

OK. That's reasonable.

> For settings (like this) that the kernel driver knows about, it should
> use a mixer control, because the control interface already has mechanisms
> to notify others of changes, and to lock controls.

OK. I select control interface with the same reasons.

> The hwdep interface is appropriate for commands that must go through the
> driver for technical reasons (such as EFC's response address), but where
> the driver does not care about the actual meaning of the command.
>
> (For other commands, like A/VC, the application can go directly through
> /dev/fw*.)

OK. I start to work for hwdep for EFC. I may ask the other questions 
later if I have.


Thanks a lot

Takashi Sakamoto


(2013年11月01日 17:36), Clemens Ladisch wrote:
> Takashi Sakamoto wrote:
>> my drivers have PCM rules for auto-adjustment of rate/channels. Should
>> I remove them and fix rate/channels according to current sampling rate?
>
> When the clock source is internal or the PC, the driver can change the
> sample rate.  When the clock source is external, the rate is constrained.
>
>> As long as I know, this type of device changes its channel formation
>> of AMDTP stream according to current sampling rate and current digital
>> input interface. The driver can get current sampling rate by AV/C
>> command but cannot get current digital input interface because it's
>> 'write-only'.
>>
>> For this setting, which is better for control panel/mixer application,
>> control interface or hwdep interface with firewire.h?
>
> For settings (like this) that the kernel driver knows about, it should
> use a mixer control, because the control interface already has mechanisms
> to notify others of changes, and to lock controls.
>
> The hwdep interface is appropriate for commands that must go through the
> driver for technical reasons (such as EFC's response address), but where
> the driver does not care about the actual meaning of the command.
>
> (For other commands, like A/VC, the application can go directly through
> /dev/fw*.)
>
>
> Regards,
> Clemens