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