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