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