ALSA control service in user space

[Takashi Sakamoto]

Hi,

Today I released hinawa-rs[1], Rust bindings to libhinawa v2.0[2].

Aug 2018 I sent a message[3] about new releases of libhinawa/hinawa-utils.
In the releases, I used Python 3 to write tools for audio and music units
on IEEE 1394 bus, supported by ALSA firewire stack. The attempt is
successful to make my understandings further about vendor-dependent
protocols.

Earlier the message, Nov 2016 I had a presentation about ALSA device
control service in user space[4]. The idea requires server program to
perform some tasks below in user space:

 * register control element set into ALSA control core for existent card instance
 * dispatch control event from ALSA control applications
 * communicate with device to operate its functions such as volume control
 * dispatch any event from the device.

The registered control element set can be handled transparently by ALSA
control applications such as amixer. When the application operates the
added control element, events are delivered to the server program. Then
the server program communicates with the device for the operation.

Now instead of Python 3, I select Rust language to write the server
programs for audio and music units on IEEE 1394 bus. The hinawa-rs helps
the third and fourth of the above tasks.

For the first and second task, I wrote some libraries in alsa-gobject
project[5]. The demonstration by Python 3 is public[6]. I already write
alsa-gobject-rs which includes Rust bindings for the libraries. It's not
public yet since I make no official releases of alsa-gobject itself.

At the same time, I already write the prototype of server programs itself
and it works well in my local. The code base already reaches 28,000 lines
even if it supports the limited number of devices. I realized again that
it was a better decision not to implement them in kernel land.


As IEEE 1394 bus becomes legacy, the audio and music units is outdated.
One of my motivation to continue the development is the idea of control
service in use space itself since the idea is also available for USB Audio
as well.

When developers work for devices with vendor-dependent protocol, the idea
helps the developer because user space applications can communicate with
the device via USB character device. For example, I recently saw an attempt
by Guy Sherman for US-4x4 Utils[7]. As a quick glance to his repository[8],
vendor-dependent command is used to operate the device. For this kind of
work, the idea is available as well to produce transparent control element
set.


Anyway I'm going to make official release of alsa-gobject as a next step
toward the idea.

[1] https://github.com/takaswie/hinawa-rs
[2] https://github.com/takaswie/libhinawa
[3] https://www.alsa-project.org/pipermail/alsa-devel/2018-August/139448.html
[4] https://github.com/takaswie/presentations/blob/master/20161101/content.md
[5] https://github.com/alsa-project/alsa-gobject
[6] 'self.open(card_id)' should be 'self.open(card_id, 0)' now
https://mailman.alsa-project.org/pipermail/alsa-devel/2019-December/159339.html
[7] https://lists.linuxaudio.org/archives/linux-audio-dev/2020-May/037774.html
[8] https://github.com/guysherman/tascam-util

Regards

Takashi Sakamoto