[RFT] ALSA control service programs for Digidesign Digi 002/003 family and Tascam FireWire series
Hi,
This is request-for-test (RFT) to the ALSA control service programs for Digidesign Digi 002/003 family and Tascam FireWire series. The programs are available in 'topic/services-for-dg00x-tascam' of below repository, and the RFT is corresponding to Pull Request #1:
* https://github.com/alsa-project/snd-firewire-ctl-services/
Background ----------
The models in above family and series are already supported by drivers in ALSA firewire stack for their isochronous packet stream functionality. Although the drivers allow userspace applications to process PCM frames and MIDI messages in the packet streaming, they doesn't support the other functionalities such as volume control since it can be achieved by any usespace applications of Linux firewire subsystem.
The service programs added by this patchset are for the supplemental functionality to control the models by asynchronous packet transaction or to process a part of data transferred by the isochronous packet stream.
In detail, please read README.rst in the repository[1]. You can see some illustrations.
How to build -------------
The project depends on several libraries in below repositories:
* glib[2] * alsa-gobject v0.1.0[3] * libhinawa v2.0.0[4]
Before building it, please install them with gobject-introspection support.
The project is written by Rust programming language[5] and packaged by cargo[6]. To build, just run below commands in the environment to connect to internet:
``` $ git clone https://github.com/alsa-project/snd-firewire-ctl-services.git -b topic/services-for-dg00x-tascam $ cd snd-firewire-ctl-services $ cargo build ```
All of required crates are downloaded automatically, then start build.
Executables -----------
The added executables are listed below:
* snd-firewire-digi00x-ctl-service * snd-firewire-tascam-ctl-service
When running, the programs add and maintain control elements, then enter event loop to dispatch events. Thes elements are visible and manipulable for any userspace applications. The program dispatch any manipulation event for transactions to control actual device. For console model and FE-8 in Tascam FireWire series, the program adds and maintains port in ALSA Sequencer.
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. ```
For models of Tascam FireWire series except for FE-8, the executable should run with 'snd' as its first option and the numerical ID of sound card as second option. Tascam FE-8 is supported by the service program but not supported by ALSA firewire stack since it doesn't handle isochronous packet streaming. For FE-8, the executable should run with 'fw' as its first option and the numerical ID of firewire character device.
``` Usage: snd-firewire-tascam-ctl-service SUBSYSTEM ID
where: SUBSYSTEM: The name of subsystem; 'snd' or 'fw' ID: The numerical ID of sound card or fw character device ```
It's easy to run the executables by cargo, like:
``` $ cargo run --bin snd-firewire-digi00x-ctl-service 2 ```
Receiving SIGTERM signal terminates the event loop, then the program finishes.
Access permissions for relevant character devices --------------------------------------------------
The executables manipulate below character devices to dispatch, convert, and emit event from end to end. The '%u' is the numerical number in each subsystem:
* ALSA control character device (/dev/snd/controlC%u) * ALSA hwdep character device (/dev/snd/hwC%uD%u) * Linux firewire character device (/dev/fw%u)
Additionally, the service program for Tascam FireWire series manipulates ALSA sequencer character device (/dev/snd/seq) to handle events of control surface for console model. Users should pay enough attention to access permission for the above character devices when running the service program.
Feedback --------
Any feedback is welcome. For questions, please use mailing list in alsa-devel or alsa-users[7]. For issues, please use service of github.com[8].
Issues ------
The name of control elements are not fixed yet since the convention of name for element set is not clear yet for recording equipment.
Users may feel inconvenience to which channel corresponds to which physical port. Furthermore, in the case that element set includes several elements, it's unclear that which element corresponds to which physical port as well. ALSA control core has no feature for the above issues at present.
[1] https://github.com/alsa-project/snd-firewire-ctl-services [2] https://gitlab.gnome.org/GNOME/glib [3] https://github.com/alsa-project/alsa-gobject/ [4] https://github.com/alsa-project/libhinawa [5] https://www.rust-lang.org/ [6] https://doc.rust-lang.org/cargo/ [7] https://www.alsa-project.org/wiki/Mailing-lists [8] https://github.com/alsa-project/snd-firewire-ctl-services/issues
Regards
Takashi Sakamoto
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.
Jaroslav
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
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
Hi,
On Tue, Jul 07, 2020 at 09:56:51PM +0900, Takashi Sakamoto wrote:
How to build
The project depends on several libraries in below repositories:
- glib[2]
- alsa-gobject v0.1.0[3]
- libhinawa v2.0.0[4]
Before building it, please install them with gobject-introspection support.
The project is written by Rust programming language[5] and packaged by cargo[6]. To build, just run below commands in the environment to connect to internet:
$ git clone https://github.com/alsa-project/snd-firewire-ctl-services.git -b topic/services-for-dg00x-tascam $ cd snd-firewire-ctl-services $ cargo buildAll of required crates are downloaded automatically, then start build.
I merged the above topic branch into master branch. Please use HEAD of master branch if you're interested in it.
Thanks
Takashi Sakamoto
participants (2)
-
Jaroslav Kysela -
Takashi Sakamoto