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

[Jaroslav Kysela <perex@perex.cz>]

Dne 08. 07. 20 v 16:44 Takashi Sakamoto napsal(a):
> 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.

The id can be changed via sysfs:

$ LC_ALL=C ls -la /sys/class/sound/card0/id
-rw-r--r--. 1 root root 4096 Jul  3 11:58 /sys/class/sound/card0/id

I believe that we should offer tools and let users to select the usage way.

					Jaroslav

> 
> 
> Thanks
> 
> Takashi Sakamoto
> 


-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.