[alsa-devel] firewire mixer interface -- was Re: [PATCH 11/11] ALSA: digi00x: apply double-oh-three algorism to multiplex PCM samples

[Takashi Iwai]

At Fri, 20 Mar 2015 23:45:40 +0900,
Takashi Sakamoto wrote:
> 
> On Mar 20 2015 23:13, Takashi Iwai wrote:
> > At Fri, 20 Mar 2015 22:51:25 +0900,
> > Takashi Sakamoto wrote:
> >>
> >> On Mar 20 2015 22:35, Takashi Iwai wrote:
> >>>> I don't think it possible to argue the other ALSA developers for going
> >>>> to include such vendor-specific or model-specific huge codes to
> >>>> alsa-lib... (Except for intel HDA)
> >>>
> >>> Why not implementing as a plugin?
> >>
> >> As long as I know, we cannot write any configuration to load it for 'hw'
> >> node. On the other hand, when adding any nodes like 'bebob' or 'dice',
> >> they always stay in alsa-lib configuration space even if there're no
> >> actual devices connected.
> >>
> >> If my understanding is wrong, please inform it to me.
> > 
> > You seem mixing up how to use the plugin setup and how to write the
> > plugin...  The usage with a plugin might be more complex indeed, but
> > it's more or less same no matter whether you implement in alsa-lib
> > itself or implement as an external plugin.
> 
> Sorry, but I consider about one-step future.
> 
> I think it possible to discuss constructively about such plugins for
> alsa-plugins, while its usage is not so easy for usual users of FireWire
> audio devices. I can imagine to receive much requests about
> improvements, then consider about including it to alsa-lib itself. But
> this idea may be hard to achieve because of the reasons I describe.

OK, point taken.  Then it's no matter whether plugin or not.  Rather a
question is whether it works out-of-the-box without any extra
configuration, right?

It'd be possible to achieve this in pure alsa-lib config, but it can
be complicated.  The alsa-lib config may choose different sub-config
depending on the hardware component.  The current per-card config
setup is already so, and USB-audio.conf contains yet more per-driver
extra config.

But I don't also push this as the best solution, either.  My comment
was only about the implementation detail *if* we want to implement as
an alsa-lib functionality.  Any better solution is more welcome.

However, what would be the better alternative for the mixer setup
including the clock source selection?  Invoking another mixer program
may annoy people (as least already two people complained :)


Takashi