18 Jul
2020
18 Jul
'20
6:18 a.m.
Hi,
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:
* https://github.com/alsa-project/snd-firewire-ctl-services/
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)
* Echo Audio Audiofire 8 (since Jul 2009)
* Echo Audio Audiofire 2
* Echo Audio Audiofire 4
* Echo Audio Audiofire Pre8
* Gibson Robot Interface Pack (RIP) for Robot Guitar series
Background
----------
The models with Fireworks board module are already supported by ALSA
fireworks driver for their isochronous packet stream functionality
and vendor-specific transaction. Although the driver allows userspace
applications to process PCM frames and MIDI messages in the packet
streaming, it doesn't support the other functionalities such as volume
control since it can be achieved by any usespace application which
executes ioctl(2) to ALSA hwdep character device for the transaction.
The service program is to satisfy the demand to control the models.
ALSA control applications can request the control by IPC to the service
program.
In detail of mechanism, 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/service-for-efw
$ cd snd-firewire-ctl-services
$ cargo build
```
All of required crates are downloaded automatically, then start build.
Executables
-----------
After building, `snd-fireworks-ctl-service` executable is available.
When running, the program adds and maintains control elements, then enter
event loop to dispatch events. The added elements are visible and manipulable
for any userspace applications. The program dispatch any manipulation
event for transactions to control actual device.
The executable has an option for the numerical ID of sound card.
```
Usage:
snd-fireworks-ctl-service CARD_ID
where:
CARD_ID: The numerical ID of sound card.
```
It's easy to run the executable by cargo, like:
```
$ cargo run --bin snd-fireworks-ctl-service 2
```
Receiving SIGTERM signal terminates the event loop, then the program
finishes.
During runtime, any ALSA control applications can enumerate and manipulate
the added control elements. This is an example of Echo Audio AudioFire 2:
```
$ amixer -c 2 controls
numid=33,iface=MIXER,name='clock-detect'
numid=2,iface=MIXER,name='clock-rate'
numid=1,iface=MIXER,name='clock-source'
numid=36,iface=MIXER,name='input-meter'
numid=34,iface=MIXER,name='midi-in-detect'
numid=35,iface=MIXER,name='midi-out-detect'
numid=6,iface=MIXER,name='monitor-gain'
numid=7,iface=MIXER,name='monitor-gain',index=1
numid=8,iface=MIXER,name='monitor-gain',index=2
numid=9,iface=MIXER,name='monitor-gain',index=3
numid=10,iface=MIXER,name='monitor-gain',index=4
numid=11,iface=MIXER,name='monitor-gain',index=5
numid=12,iface=MIXER,name='monitor-mute'
numid=13,iface=MIXER,name='monitor-mute',index=1
numid=14,iface=MIXER,name='monitor-mute',index=2
numid=15,iface=MIXER,name='monitor-mute',index=3
numid=16,iface=MIXER,name='monitor-mute',index=4
numid=17,iface=MIXER,name='monitor-mute',index=5
numid=24,iface=MIXER,name='monitor-pan'
numid=25,iface=MIXER,name='monitor-pan',index=1
numid=26,iface=MIXER,name='monitor-pan',index=2
numid=27,iface=MIXER,name='monitor-pan',index=3
numid=28,iface=MIXER,name='monitor-pan',index=4
numid=29,iface=MIXER,name='monitor-pan',index=5
numid=18,iface=MIXER,name='monitor-solo'
numid=19,iface=MIXER,name='monitor-solo',index=1
numid=20,iface=MIXER,name='monitor-solo',index=2
numid=21,iface=MIXER,name='monitor-solo',index=3
numid=22,iface=MIXER,name='monitor-solo',index=4
numid=23,iface=MIXER,name='monitor-solo',index=5
numid=38,iface=MIXER,name='monitoring'
numid=37,iface=MIXER,name='output-meter'
numid=31,iface=MIXER,name='output-mute'
numid=30,iface=MIXER,name='output-volume'
numid=4,iface=MIXER,name='playback-mute'
numid=5,iface=MIXER,name='playback-solo'
numid=3,iface=MIXER,name='playback-volume'
numid=32,iface=MIXER,name='stream-playback-routing'
```
Access permissions for relevant character devices
--------------------------------------------------
The executable manipulates below character devices to dispatch, and emit
events from end to end. The '%u' is the numerical number of instance 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)
Feedback
--------
Any feedback is welcome. For questions, please use mailing list of 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
23 Jul
23 Jul
8:40 a.m.
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?
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.
--
Len Ovens
www.ovenwerks.net
5:51 p.m.
Hi Len,
On Wed, Jul 22, 2020 at 09:40:01PM -0700, Len Ovens wrote:
On Sat, 18 Jul 2020, Takashi Sakamoto wrote:
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.
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? 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
10:56 p.m.
On Thu, 23 Jul 2020, Takashi Sakamoto wrote:
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
That sounds like what I am seeing. Perhaps alsa-restore.service. I will
try with that disabled. Yes that is the difference, it works as expected.
I would guess this module would be added to alsa before
alsa-restore.service after release. Restore would then be able to fix my
clock settings.
I have added comments to issues that are closed to indicate what I have
tested. The closed issues do seem to be fixed.
--
Len Ovens
www.ovenwerks.net
$ 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
24 Jul
24 Jul
5:37 a.m.
On Thu, Jul 23, 2020 at 11:56:35AM -0700, Len Ovens wrote:
On Thu, 23 Jul 2020, Takashi Sakamoto wrote:
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
That sounds like what I am seeing. Perhaps alsa-restore.service. I will try
with that disabled. Yes that is the difference, it works as expected. I
would guess this module would be added to alsa before alsa-restore.service
after release. Restore would then be able to fix my clock settings.
As long as I know, alsactl has some bugs to represent the content of
control element set in cache file.
I guess you hit this bug since the feature called as user-define control
element set had not been used for a long time except for alsa-lib
'softvol' PCM plugin.
If alsactl worked expectedly, the order to execute the system service
for alsactl and the service program does not matter as long as they
don't run simultaneously.
$ 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 I have added comments to issues that are closed to
indicate what I have
tested. The closed issues do seem to be fixed.
I see your comments. Thanks for your help and patience! I merged the
topic issue for this RFT into master now.
Regards
Takashi Sakamoto
6:03 a.m.
On Fri, Jul 24, 2020 at 10:37:35AM +0900, Takashi Sakamoto wrote:
On Thu, Jul 23, 2020 at 11:56:35AM -0700, Len Ovens
wrote:
Oops. I overloop your demand to restore status of control element set
automatically. I register an issue for this topic and queued for my future
work:
Restart alsa-restore.service after launching the service program
https://github.com/alsa-project/snd-firewire-ctl-services/issues/9
Thanks
Takashi Sakamoto
On Thu, 23 Jul 2020, Takashi Sakamoto wrote:
That sounds like what I am seeing. Perhaps alsa-restore.service. I will try
with that disabled. Yes that is the difference, it works as expected. I
would guess this module would be added to alsa before alsa-restore.service
after release. Restore would then be able to fix my clock settings.
As long as I know, alsactl has some bugs to represent the content of
control element set in cache file.
I guess you hit this bug since the feature called as user-define control
element set had not been used for a long time except for alsa-lib
'softvol' PCM plugin.
If alsactl worked expectedly, the order to execute the system service
for alsactl and the service program does not matter as long as they
don't run simultaneously.
> $ 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
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
1579
days inactive
1585
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
2 participants
participants (2)
-
Len Ovens -
Takashi Sakamoto