[alsa-devel] Need help implementing an external PCM/control plugin pair

[Takashi Sakamoto]

Hi,

On Feb 16 2018 19:12, Dimitris Papavasiliou wrote:
> I'm in the process of putting together a loudness compensation plugin 
> for ALSA.  The filtering part is implemented as an external PCM plugin 
> and it is, more or less, ready, meaning that you can set its parameters 
> via configuration options and it'll happily filter away in real time. 
> I'm trying now to create a matching mixer plugin, to allow on-the-fly 
> adjustment of the parameters, and I'm not sure what the best way of 
> accomplishing that would be.  My main concerns are:
>
> 1. I've figured out how to create a basic external control plugin, that 
> would allow me to expose a set of controls, which the user can fiddle 
> with, using alsamixer et al., but what would be the best way of 
> communicating changes in the values to the PCM plugin?  I could imagine 
> using methods external to ALSA, such as a file with stored values, which 
> the ctl plugin updates and which the PCM plugin monitors for changes, or 
> perhaps I could try to open the mixer from inside the PCM plugin, set 
> callbacks for each of its elements and enter a 
> snd_mixer_wait/snd_mixer_handle_events loop, in a separate thread of 
> course.  Is there reason to prefer one way over the other?  Perhaps 
> there is a better way, I'm not aware of?
>
> 2. I'd like to support event subscription/notification, but I'm not sure 
> how to make that work.  My understanding (from searching the net and 
> looking at ALSA's source), is that I need to provide some sort of file 
> descriptor, which the subscribing code can poll, so as to block until 
> there's an update.  Since I have no obvious candidates for such a file, 
> I've tried creating a pipe, handing one end to the control plugin upon 
> initialization and then writing single bytes to the other end when 
> there's a change in one of the controls.  This works but, as far as I 
> can see, the pipe is never actually read from, from the subscribing 
> code, so that I would have to manually read from it somehwere, say in 
> the read_event callback, in order to flush it.  In the end, I'll 
> probably use the descriptor from an inotify watch on the file where the 
> plugin stores the control settings, but is this a valid approach 
> overall?  Is there some documentation specifying the exact way in which 
> poll descriptors are handled by ALSA (in the case of an extrnal CTL 
> plugin), that I've missed?  If not, are my assumptions above (that the 
> descriptor is only polled and that its contents are never actually read) 
> correct?
> 
> 3. Finally, and although this is not essential, I'd like to provide 
> metadata for some controls, to support dB ranges, as that's the most 
> natural way to set them.  I see hints that this is supported for 
> external control plugins (SND_CTL_EXT_ACCESS_TLV_READ/WRITE, the 
> snd_ctl_ext_tlv_rw_t callback), but I'm not sure how to implement it. Is 
> it documented somewhere?  If not, could someone describe the basic 
> approach?

ALSA control core has a feature called as 'user-defined control element 
set'. This will help your work, in my opinion. For example, alsa-lib 
'softvol' PCM plugin utilizes this feature to accomplishment 
configurable volumes by the others[1]. This feature supports metadata by 
TLV (Type-Length-Value) and eventing to subscribers as well.

The alsa-lib includes a test program for this feature, which I wrote[2]. 
This may help your work by its actual code, I think[2].

[1] 
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/pcm/pcm_softvol.c;h=8bb4a397b80ebba52a995a46417b69e78f5ea52b;hb=HEAD#l714
[2] 
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=test/user-ctl-element-set.c;h=e94152b952e4d724bc109393df29bf4519f60b31;hb=HEAD


Regards

Takashi Sakamoto