Hi Clemens,
On Sep 6 2016 15:28, Clemens Ladisch wrote:
Takashi Sakamoto wrote:
When detecting some audio and music units on IEEE 1394 bus, the daemon program adds some element sets and start listening to them. If ALSA control applications changes state of elements in the element sets, the daemon catches the event and configure these units by hardware- specific ways.
If these controls are removed when the daemon exits, the normal alsactl mechanism of saving/restoring does not work.
Yes, because many of supported audio and music units on IEEE 1394 have on-board non-volatile memory to restore current state every at rebooting. I have a plan to utilize it in the daemon. In this case, restoring from alsactl is conflicts to the feature.
Besides, the rest of units mostly have no feature corresponding to control elements.
In detail: - With control elements and on-board non-volatile memory - DM1000/1100/1500 with BeBoB firmware: - Dice: - Fireworks board module: - With control elements and non on-board memory - OXFW - No control elements (controlled via MIDI messages) - firewire-tascam: - Unknown - firewire-digi00x (certainly have some control elements) - firewire-motu (not yet) - firewire-rme (not yet)
I guess the reason for removing the controls is to avoid the case that they are non-functional if the daemon is not running?
Yes. For the case, I plan to restart the daemon by 'Restart' directive of systemd service unit file. Then, in current ALSA control implementation, elements remains.
In ALSA control core, the maximum number of user-defined element sets is limited up to 32. So left elements causes an issue that the daemon cannot add more element sets in a half of way to start.
Of course, I can program the daemon to check the name of adding/added elements. But to avoid the cumbersome, I simply hope to constrain life time of element set to file descriptors.
However I have a hesitation for this direction; a daemon for control service. It might be more huge than what I require, and larger work against rest of my free time. In short, most of what I need are satisfied with the combination of libhinawa/hinawa-utils, just to control the units. I don't prefer over-specification[0]. But I hear users seem to hope to control their units via ALSA control interface.
Well, this patchset is for more generic issues discussed longer term. I'd get your comments regardless of an idea of the server.
[0] ffado-dbus-server/ffado-mixer is this kind of software.
Regards
Takashi Sakamoto