[alsa-devel] Softvol only after device has opened
I'm working on implementing support for a MEMS microphone with an I2S connection. Since the microphone has no controls but simply outputs I2S data from the word go, this means that any gain must be applied later. (Microphones of this type are generally specified at outputting 0 dB FS at some rediculously high SPL, 120 dB SPL being typical).
Since we use 16 bit audio in our (SOC) system, I'm trying to apply gain using the softvol ALSA plugin, before converting to 16 bit audio (the microphone outputs 24 bit audio).
One thing though, the 'softvol' plugin very correctly creates a mixer control and it all works fine, but only after the device has been opened. Before that the mixer control doesn't seem to exist, which means that we cannot adjust the gain until the device is opened by some application.
Is this intentional, a bug, or something that is misconfigured on my part?
/Ricard
Ricard Wanderlof wrote:
One thing though, the 'softvol' plugin very correctly creates a mixer control and it all works fine, but only after the device has been opened. Before that the mixer control doesn't seem to exist, which means that we cannot adjust the gain until the device is opened by some application.
Before a device using a plugin is opened, no code from that plugin is run.
Anyway, softvol mixer controls can be saved and restored with the usual "alsactl store" and "alsactl restore" mechanism. If you do not want to save all mixer controls, or if your system does not have nonvolatile storage, create a file containing only that control and tell alsactl to restore from it.
Regards, Clemens
On Tue, 9 Jun 2015, Clemens Ladisch wrote:
Ricard Wanderlof wrote:
One thing though, the 'softvol' plugin very correctly creates a mixer control and it all works fine, but only after the device has been opened. Before that the mixer control doesn't seem to exist, which means that we cannot adjust the gain until the device is opened by some application.
Before a device using a plugin is opened, no code from that plugin is run.
Anyway, softvol mixer controls can be saved and restored with the usual "alsactl store" and "alsactl restore" mechanism. If you do not want to save all mixer controls, or if your system does not have nonvolatile storage, create a file containing only that control and tell alsactl to restore from it.
Can "alsactl restore" be run before the device is opened then?
/Ricard
On Tue, 9 Jun 2015, Clemens Ladisch wrote:
Ricard Wanderlof wrote:
Can "alsactl restore" be run before the device is opened then?
Many distributions run "alsactl restore" in some startup script. You can execute it yourself whenever you want.
What I was getting at was that although I can't do:
$ amixer sset Capture 192
if Capture is defined by the softvol plugin, and I haven't opened the device prior to running amixer, however
$ alsactl restore 0:
works, assuming that I've saved the settings previously, even before the device is opened. I can understand that this is very useful and desired, but given that the underlying control does not yet exist, it puzzles me that it actually works.
/Ricard
Ricard Wanderlof wrote:
What I was getting at was that although I can't do:
$ amixer sset Capture 192
if Capture is defined by the softvol plugin, and I haven't opened the device prior to running amixer, however
$ alsactl restore 0:
works, assuming that I've saved the settings previously, even before the device is opened. I can understand that this is very useful and desired, but given that the underlying control does not yet exist, it puzzles me that it actually works.
Have a look at /var/lib/asound.state. "alsactl store" marks any user- space controls; when "alsactl restore" sees this flag, it will explicitly recreate the control.
Regards, Clemens
On Tue, 9 Jun 2015, Clemens Ladisch wrote:
Ricard Wanderlof wrote:
What I was getting at was that although I can't do:
$ amixer sset Capture 192
if Capture is defined by the softvol plugin, and I haven't opened the device prior to running amixer, however
$ alsactl restore 0:
works, assuming that I've saved the settings previously, even before the device is opened. I can understand that this is very useful and desired, but given that the underlying control does not yet exist, it puzzles me that it actually works.
Have a look at /var/lib/asound.state. "alsactl store" marks any user- space controls; when "alsactl restore" sees this flag, it will explicitly recreate the control.
And there is no other way to recreate the control using an application than to use alsactl then?
/Ricard
At Tue, 9 Jun 2015 16:32:35 +0200, Ricard Wanderlof wrote:
On Tue, 9 Jun 2015, Clemens Ladisch wrote:
Ricard Wanderlof wrote:
What I was getting at was that although I can't do:
$ amixer sset Capture 192
if Capture is defined by the softvol plugin, and I haven't opened the device prior to running amixer, however
$ alsactl restore 0:
works, assuming that I've saved the settings previously, even before the device is opened. I can understand that this is very useful and desired, but given that the underlying control does not yet exist, it puzzles me that it actually works.
Have a look at /var/lib/asound.state. "alsactl store" marks any user- space controls; when "alsactl restore" sees this flag, it will explicitly recreate the control.
And there is no other way to recreate the control using an application than to use alsactl then?
There is other way, of course. It's no magic. alsactl just creates a user-space control element using the normal API.
Takashi
On Tue, 9 Jun 2015, Takashi Iwai wrote:
Have a look at /var/lib/asound.state. "alsactl store" marks any user- space controls; when "alsactl restore" sees this flag, it will explicitly recreate the control.
And there is no other way to recreate the control using an application than to use alsactl then?
There is other way, of course. It's no magic. alsactl just creates a user-space control element using the normal API.
Yes, of course that's doable, I was wondering if there's some other application that I don't know about that could do it. I.e. if there's a startup script that normally uses amixer to set up default settings, is it possible to add something to that script rather than to write a separate application to create the user control, which of course is doable too.
/Ricard
At Tue, 9 Jun 2015 16:45:32 +0200, Ricard Wanderlof wrote:
On Tue, 9 Jun 2015, Takashi Iwai wrote:
Have a look at /var/lib/asound.state. "alsactl store" marks any user- space controls; when "alsactl restore" sees this flag, it will explicitly recreate the control.
And there is no other way to recreate the control using an application than to use alsactl then?
There is other way, of course. It's no magic. alsactl just creates a user-space control element using the normal API.
Yes, of course that's doable, I was wondering if there's some other application that I don't know about that could do it. I.e. if there's a startup script that normally uses amixer to set up default settings, is it possible to add something to that script rather than to write a separate application to create the user control, which of course is doable too.
Just open PCM once and close. That should suffice :)
Other than that, an easy way is to run alsactl restore with a snippet of user-space ctl element definition as Clemens suggested.
Takashi
On Tue, 9 Jun 2015, Takashi Iwai wrote:
There is other way, of course. It's no magic. alsactl just creates a user-space control element using the normal API.
Yes, of course that's doable, I was wondering if there's some other application that I don't know about that could do it. I.e. if there's a startup script that normally uses amixer to set up default settings, is it possible to add something to that script rather than to write a separate application to create the user control, which of course is doable too.
Just open PCM once and close. That should suffice :)
Other than that, an easy way is to run alsactl restore with a snippet of user-space ctl element definition as Clemens suggested.
Ok. Thanks!
/Ricard
participants (3)
-
Clemens Ladisch -
Ricard Wanderlof -
Takashi Iwai