Re: include/uapi/firewire.h for other firewire drivers

[Takashi Sakamoto <o-takashi@sakamocchi.jp>]

Hi, Clemens,

I have two more questions.

> (For example, the sample rate is set by the application on the
> ALSA device; it would be a bad idea for the driver
> to _ask_ the control panel application to change it.)

I had a doubt that all of models can follow this rule because there are 
some models which is not designed for stand-alone use. This type of 
device cannot work without connection/streams so I assumed that changing 
sampling rate or clock source brings some bad situations.

But now I confirmed all of models which I have can follow this rule.

Related to this, my drivers have PCM rules for auto-adjustment of 
rate/channels. Should I remove them and fix rate/channels according to 
current sampling rate?

> This is another example of a setting that must be in the
> kernel driver.

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?


Thanks for your patience to answer my questions.

Takashi Sakamoto


(2013年10月28日 17:29), Clemens Ladisch wrote:
> Takashi Sakamoto wrote:
>>> Because every device can have settings that should not be changed
>>> while streaming.
>>
>> Currently my Fireworks/BeBoB driver give Control interfaces for these
>> settings, like changing sampling rate, switching digital interface.
>> The primarry purpose of these is the same, a prevention from stopping
>> streaming. The secondary purpose is debug codes for these functionality.
>>
>> But based on firewire.h interface, it is the applications'
>> responsibility, not drivers'. Is my understanding correct?
>
> Yes; the intent is for the kernel driver to handle only those settings
> that would be impossible or very difficult to handle with a separate
> user space process.  (For example, the sample rate is set by the
> application on the ALSA device; it would be a bad idea for the driver to
> _ask_ the control panel application to change it.)
>
>> Here some devices has "write-only" settings. For such device, my
>> driver remember these settings. If the applications has such
>> responsibility, there may be some inconsistency.
>
> This is another example of a setting that must be in the kernel driver.
>
>
> Regards,
> Clemens
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel