ALSA control service in user space

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

Re: ALSA control service in user space

[Scott Bahling]

[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]

Hi Takashi,

On Wed, 2020-06-03 at 19:05 +0900, Takashi Sakamoto wrote:
> Hi,
> 
> Today I released hinawa-rs[1], Rust bindings to libhinawa v2.0[2].

...

> 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.

...

What does this mean for the future of hinawa-utils? I have created an OSC
server interface[1] to the Tascam FW-1884 control surface using a fork of
the hinawa-utils with a few enhancements[2]. The OSC server works great for
controlling applications like Ardour with the FW-1884. I was just cleaning
up the code and was prepared to submit my patches for hinawa-utils, but if
that will go unmaintained, I might just integrate the hinawa-utils parts
into my OSC server code and only depend on libhinawa directly. What do you
recommend?

[1] https://gitlab.com/tascam-fw-1884/tascam-fw-osc
[2] https://github.com/sbahling/hinawa-utils/compare/master...fw-1884

Regards,

Scott

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: ALSA control service in user space

[Takashi Sakamoto]

Hi Scott,

On Thu, Jun 04, 2020 at 09:02:23PM +0200, Scott Bahling wrote:
> Hi Takashi,
> 
> On Wed, 2020-06-03 at 19:05 +0900, Takashi Sakamoto wrote:
> > 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.
> 
> What does this mean for the future of hinawa-utils?

I'm sorry to puzzle you but I shift my effort of userspace applications
from hinawa-utils into the services.

As you can see, Python 3 scripts in hinawa-utils depends on 'libhinawa 1'
which produces 'Hinawa-2.0.gir'. On the other hand, libhinawa 2 produces
'Hinawa-3.0.gir'. Although hinawa-utils needs to be arranged for its
dependency to the latest libhinawa, at present I have no plan for it due
to the rest of my time... Therefore hinawa-utils is actually going to become
abandoned now at least Python 3 areas, unfortunately.

> I have created an OSC server interface[1] to the Tascam FW-1884 control
> surface using a fork of the hinawa-utils with a few enhancements[2]. The
> OSC server works great for controlling applications like Ardour with the
> FW-1884.

I'm interested in Open Sound Control protocol itself, and I would use it
if I were a developer out of alsa-project. However it's secondary option
to me if any ALSA interface assists me to achieve the aim.

Now I made the repository public[1] for your information. The 'topic/work'
branch includes the latest codes for the services[2]. You can see many
protocols are already added. (The most of them are just makeshift...)

For Tascam FireWire series, I uses two types of ALSA interfaces for
inter-process communication between the service and ALSA applications:

- interface on ALSA control character device
- interface on ALSA sequencer character device

For FW-1884, below elements are transparently visible for ALSA control
applications (e.g. amixer, qashctl):

 * clock-source
 * clock-rate
 * input-threshold
 * coax-output-source
 * master-fader-assign
 * host-mode
 * opt-output-source
 * spdif-input-source
 * monitoring (to start polling for below elements)
 * monitor-rotary (readonly)
 * solo-rotary (readonly)
 * input-meters (readonly)
 * output-meters (readonly)
 * detected-clock-source (readonly)
 * detected-clock-rate (readonly)
 * monitor-meters (readonly)
 * analog-mixer-meters (readonly)
 * monitor-mode (readonly)

Additionally, 'FW-1884' port is opened to ALSA Sequencer. The events generated
by touching control surfaces such as fader, rotary are converted to standard
MIDI messages and sent to the port. Any ALSA Sequencer application can receive
the messages via the port. Ardour is such an application.

You can see the conversion in 'src/tascam/isoch/seq_ctl.rs'[3] and everything
is hard-coded. It's possible to be more inconvenient than your implementation.

> I was just cleaning up the code and was prepared to submit my patches for
> hinawa-utils, but if that will go unmaintained, I might just integrate the
> hinawa-utils parts into my OSC server code and only depend on libhinawa
> directly. What do you recommend?
> 
> [1] https://gitlab.com/tascam-fw-1884/tascam-fw-osc
> [2] https://github.com/sbahling/hinawa-utils/compare/master...fw-1884

The integration into your repository is easy and convenient to you. I
recommend it. But I'm welcome your comment and patches for the service itself
when the service officially starts for public development.


Well, from my interests, how do you implement to blight 'REC' LEDs? It's my
concern when using ALSA Sequencer because MIDI standard has no
specification to associate LED and messages.

[1] https://github.com/takaswie/snd-firewire-ctl-services
[2] https://github.com/takaswie/snd-firewire-ctl-services/tree/topic/work/src
[3] https://github.com/takaswie/snd-firewire-ctl-services/blob/topic/work/src/tascam/isoch/seq_ctl.rs


Thanks

Takashi Sakamoto

Re: ALSA control service in user space

[Scott Bahling]

[-- Attachment #1: Type: text/plain, Size: 5464 bytes --]

Hi Takashi,

On Fri, 2020-06-05 at 10:18 +0900, Takashi Sakamoto wrote:
> Hi Scott,
> 
> On Thu, Jun 04, 2020 at 09:02:23PM +0200, Scott Bahling wrote:
> > Hi Takashi,
> > 
> > On Wed, 2020-06-03 at 19:05 +0900, Takashi Sakamoto wrote:
> > > 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.
> > 
> > What does this mean for the future of hinawa-utils?
> 
> I'm sorry to puzzle you but I shift my effort of userspace applications
> from hinawa-utils into the services.
> 
> As you can see, Python 3 scripts in hinawa-utils depends on 'libhinawa 1'
> which produces 'Hinawa-2.0.gir'. On the other hand, libhinawa 2 produces
> 'Hinawa-3.0.gir'. Although hinawa-utils needs to be arranged for its
> dependency to the latest libhinawa, at present I have no plan for it due
> to the rest of my time... Therefore hinawa-utils is actually going to become
> abandoned now at least Python 3 areas, unfortunately.
> 
> > I have created an OSC server interface[1] to the Tascam FW-1884 control
> > surface using a fork of the hinawa-utils with a few enhancements[2]. The
> > OSC server works great for controlling applications like Ardour with the
> > FW-1884.
> 
> I'm interested in Open Sound Control protocol itself, and I would use it
> if I were a developer out of alsa-project. However it's secondary option
> to me if any ALSA interface assists me to achieve the aim.
> 
> Now I made the repository public[1] for your information. The 'topic/work'
> branch includes the latest codes for the services[2]. You can see many
> protocols are already added. (The most of them are just makeshift...)
> 
> For Tascam FireWire series, I uses two types of ALSA interfaces for
> inter-process communication between the service and ALSA applications:
> 
> - interface on ALSA control character device
> - interface on ALSA sequencer character device
> 
> For FW-1884, below elements are transparently visible for ALSA control
> applications (e.g. amixer, qashctl):
> 
>  * clock-source
>  * clock-rate
>  * input-threshold
>  * coax-output-source
>  * master-fader-assign
>  * host-mode
>  * opt-output-source
>  * spdif-input-source
>  * monitoring (to start polling for below elements)
>  * monitor-rotary (readonly)
>  * solo-rotary (readonly)
>  * input-meters (readonly)
>  * output-meters (readonly)
>  * detected-clock-source (readonly)
>  * detected-clock-rate (readonly)
>  * monitor-meters (readonly)
>  * analog-mixer-meters (readonly)
>  * monitor-mode (readonly)
> 
> Additionally, 'FW-1884' port is opened to ALSA Sequencer. The events generated
> by touching control surfaces such as fader, rotary are converted to standard
> MIDI messages and sent to the port. Any ALSA Sequencer application can receive
> the messages via the port. Ardour is such an application.

Very nice! I'm particularly interested in the monitoring controls which is
currently missing and would be useful.

> You can see the conversion in 'src/tascam/isoch/seq_ctl.rs'[3] and everything
> is hard-coded. It's possible to be more inconvenient than your implementation.
> 
> > I was just cleaning up the code and was prepared to submit my patches for
> > hinawa-utils, but if that will go unmaintained, I might just integrate the
> > hinawa-utils parts into my OSC server code and only depend on libhinawa
> > directly. What do you recommend?
> > 
> > [1] https://gitlab.com/tascam-fw-1884/tascam-fw-osc
> > [2] https://github.com/sbahling/hinawa-utils/compare/master...fw-1884
> 
> The integration into your repository is easy and convenient to you. I
> recommend it. But I'm welcome your comment and patches for the service itself
> when the service officially starts for public development.
> 
> 
> Well, from my interests, how do you implement to blight 'REC' LEDs? It's my
> concern when using ALSA Sequencer because MIDI standard has no
> specification to associate LED and messages.

With Ardour OSC the state of record enable/disable for each channel is sent
using the following message format:

command           channel  state 
/strip/recenable  1        1
/strip/recenable  1        0

I listen for those events and turn the LED on or off depending on the state
of channel it's assigned to.  For a MIDI implementation if there is not a
standard, I guess you need to just pick a note or control signal to use.
There seems to be no standard for many controls and different units have
their own MIDI mappings.

An example of mappings can be found in the Ardour code[ [1]. A description
of how map MIDI messages to Ardour actions is in the docs [2]. Unfortunately
,given no standard, each application needs to be configured/adjusted to use
any particular controller. Even with my OSC implementation I have API
translation service to translate the general FW-1884 API that I came up with
to specific applications like Ardour.

I looked into MIDI briefly at first, but an OSC implementation seemed easier
and more flexible to me. I think it's a better fit for complex control
surfaces. But it's not as ubiquitous as MIDI so a MIDI implementation would
be useful.

[1] https://github.com/Ardour/ardour/tree/master/share/midi_maps
[2] https://manual.ardour.org/using-control-surfaces/generic-midi/midi-binding-maps/

Scott

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]