Re: [RFT] ALSA control service programs for Digidesign Digi 002/003 family and Tascam FireWire series

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

Hi Jaroslav,

On Tue, Jul 07, 2020 at 03:15:53PM +0200, Jaroslav Kysela wrote:
> Dne 07. 07. 20 v 14:56 Takashi Sakamoto napsal(a):
> > They have command line options. For all models of Digi 002/003 family, the
> > executable has an option for the numerical ID of sound card.
> > 
> > ```
> > Usage:
> >    snd-firewire-digi00x-ctl-service CARD_ID
> > 
> >    where:
> >      CARD_ID: The numerical ID of sound card.
> > ```
> 
> It's better to handle both card number and the card id string. In the latter
> case, the user may create independent environment and use udev or
> modprobe.conf configurations to address the devices. The card number may
> change when the plug-and-play devices are randomly connected / disconnected.
> 
> snd_card_new() - third argument.

Thanks for the comment and I also think it good idea for users to have
fixed configuration since the numerical ID of sound card differs
depending on system environment.

At the same time, I like to keep the specification of service programs
as small as possible. The numerical ID of sound card is enough to
identify target sound card, and it's sole way for it.

If implementing the idea, I need to add enough instructions about the
mechanism of card id string in kernel land so that users can utilize
it without any puzzle. Actually, the mechanism heavily depends on kernel
loadable module domain and I think it better not to consider that the
users are enough friendly to the domain.

Actually there are good tools to identify the numerical ID of user's
sound card, and usage of such tools are more friendly than module
manipulation and option documentation.

For future, I have a plan to write system service to handle udev
event and launch the service programs automatically. For the case,
the event includes enough information to construct arguments for
the service program, therefore no need to handle mapping information
and extra care of the card id string.

At last, the most of drivers in ALSA firewire stack don't support the
card id string, except for my initial work for bebob and fireworks
driver. If ALSA control core had a feature to change card id string
dynamically for existent card instance by ioctl command, or it had a
feature to maintain mapping between card id string and the other
identification such as system-wide or bus-wide UUID, I would be
willing to implement them to the drivers. At present, it's outside
of my work scope.


Thanks

Takashi Sakamoto