[alsa-devel] include/uapi/firewire.h for other firewire drivers
o-takashi at sakamocchi.jp
Thu Oct 31 09:30:20 CET 2013
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
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.
(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.
More information about the Alsa-devel