[LAD] [RFT] ALSA control service programs for Fireworks board module

[Takashi Sakamoto]

Hi Len,

On Wed, Jul 22, 2020 at 09:40:01PM -0700, Len Ovens wrote:
> On Sat, 18 Jul 2020, Takashi Sakamoto wrote:
> 
> > This is request-for-test (RFT) to the ALSA control service programs for
> > devices with Fireworks board module. The program is available in
> > 'topic/service-for-efw' of below repository, and the RFT is corresponding
> > to Pull Request #2:
> ...
> > If you have listed devices and handle them by ALSA fireworks driver, please
> > test the service program according to the below instruction.
> > 
> >  * Mackie (Loud) Onyx 1200F
> >  * Mackie (Loud) Onyx 400F
> >  * Echo Audio Audiofire 12 (till Jul 2009)
> >  * Echo Audio Audiofire 8 (till Jul 2009)
> >  * Echo Audio Audiofire 12 (since Jul 2009)
> 
> Audiofire12 (seems to have 4.8 firmware butbought used with no info)
> 
> 
> > 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/service-for-efw
> > $ cd snd-firewire-ctl-services
> > $ cargo build
> > ```
> 
> ...
> 
> > $ cargo run --bin snd-fireworks-ctl-service 2
> 
> This worked great the first time, but after the next boot alsamixer showed a
> subset of the same controls (rather than no controls found) and I could not
> restart snd-fireworks-ctl-service. Is it expected that once the above
> command has been run once there are after effects? Is there a proper way to
> install it so it runs from boot? Or is that already happening but perhaps
> happening too soon before everything is settled?
 
Hmm. The service program adds several control element sets to sound card at
starting, and it deletes the added element sets when finishing. The
system reboot is expected to have no effects since the added element sets
are deleted at the same time the sound card is disonnected.

I think that some users install system service for alsactl(1)[1]. In this
case, the system services add control element sets from cache file after
reboot. For the case the service program has a care to run with the element
sets added by the system services. The care covers the case that the service
program is terminated by the other signals than SIGTERM.

It's possible to fail to start a new process for the service program when
the old process still run because the service program holds ALSA hwdep
character device exclusively.

If the issue is certainly reproducible, I would request testers to mask
the system services once, then run the service program. If the issue still
occurs, run strace(1) to the service program and gather information to
detect where and how the service program is blocked.

> I understand this is just a test for something that will become more
> permanent in the future. So I don't know what I should expect.

I have a plan to add more service programs for audio and music units on
IEEE 1394 bus, supported by drivers in ALSA firewire stack. At the same
time, I have additional plan for system service program to listen to
udev events, then launch and maintain the service programs. This RFT is
a first step for the system service, which allows users to control
devices without adding a batch of code to kernel land.


As you know, current major tools with ALSA control API (e.g. amixer,
alsamixer) need more integration for studio-purpose devices. The
inconvenience mainly comes from alsa-lib mixer abstraction.

Additionally, current implementation of ALSA core is the lack of some
features. For example, it's convenient to add labels to each channel
of element value. In next development period of Linux kernel, I'm going
to post some patches to add the feature.

It's better idea to develop new GUI applications similar to
envy24control. However, in this time I focus on integration for
amixer/alsamixer or the smixer abstraction, but I need more time for
the work.

Anyway, thanks for your report. I already found some bugs and added
patches to fix them. The combination of the service programs and ALSA
standard tools is not enough for user's satisfaction, but it means that
more integration is required for ALSA in the area of recording equipment.

[1] https://github.com/alsa-project/snd-firewire-ctl-services/tree/topic/work


Thanks

Takashi Sakamoto