About ALSA dummy module: support customized mixer volume leveling
Hello Takashi (and the alsa community),
This is YJ Lee from chromium.org.
I'm thinking about extending the ALSA dummy module to support customized volume leveling. It will be very useful to test devices with different volume granularity. Currently this module is using hard-coded mixer volume leveling, from min=-50 to max=100.
See L716: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/t...
My plan (A) is to expose 2 more additional module parameters and replace a few occurrences, from L742-750.
Another plan (B) is to leverage the current existing module parameter:model, and make the dummy-module to be able to accept models with customized volume leveling. New dummy models can be provided as configuration files, and be used in the same way as how currently existing dummy models (L146-213) are used. However, it's a bit over-engineering from the original purpose.
What do you think about these plans? Any insight you (and the alsa community) can provide will be greatly appreciated.
Best, YJ
On Thu, 08 Sep 2022 07:26:02 +0200, YJ Lee wrote:
Hello Takashi (and the alsa community),
This is YJ Lee from chromium.org.
I'm thinking about extending the ALSA dummy module to support customized volume leveling. It will be very useful to test devices with different volume granularity. Currently this module is using hard-coded mixer volume leveling, from min=-50 to max=100.
See L716: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/t...
My plan (A) is to expose 2 more additional module parameters and replace a few occurrences, from L742-750.
Another plan (B) is to leverage the current existing module parameter:model, and make the dummy-module to be able to accept models with customized volume leveling. New dummy models can be provided as configuration files, and be used in the same way as how currently existing dummy models (L146-213) are used. However, it's a bit over-engineering from the original purpose.
What do you think about these plans? Any insight you (and the alsa community) can provide will be greatly appreciated.
Only for volume min/max, module options may be an easier way, IMO.
OTOH, if we want to adjust more stuff, another possibility is to extend the proc file. It currently supports the dynamic changes of PCM parameters, but we can extend it or add a new proc file for adjusting other stuff, too. So the question is what else we want to allow changing.
thanks,
Takashi
On Thu, Sep 8, 2022 at 4:16 PM Takashi Iwai tiwai@suse.de wrote:
On Thu, 08 Sep 2022 07:26:02 +0200, YJ Lee wrote:
Hello Takashi (and the alsa community),
This is YJ Lee from chromium.org.
I'm thinking about extending the ALSA dummy module to support customized volume leveling. It will be very useful to test devices with different volume granularity. Currently this module is using hard-coded mixer volume leveling, from min=-50 to max=100.
See L716: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/t...
My plan (A) is to expose 2 more additional module parameters and replace a few occurrences, from L742-750.
Another plan (B) is to leverage the current existing module parameter:model, and make the dummy-module to be able to accept models with customized volume leveling. New dummy models can be provided as configuration files, and be used in the same way as how currently existing dummy models (L146-213) are used. However, it's a bit over-engineering from the original purpose.
What do you think about these plans? Any insight you (and the alsa community) can provide will be greatly appreciated.
Only for volume min/max, module options may be an easier way, IMO.
OTOH, if we want to adjust more stuff, another possibility is to extend the proc file. It currently supports the dynamic changes of PCM parameters, but we can extend it or add a new proc file for adjusting other stuff, too. So the question is what else we want to allow changing.
thanks,
Takashi
Hi Takashi,
Thanks for your quick reply! I can't express my gratitude enough. Will stick with plan (A).
Additionally, I'll take some time to read it and learn how to use the proc file. Compared with snd-dummy, I've plugged in a physical USB headset and saw some read-only files (usb*) under /proc/asound/cardX. By extending the proc file, are you suggesting we can change those into writable so ALSA will understand and make corresponding changes, (e.g. 'change' the dummy card into a USB sound card)? Can you tell me more about how to extend or add a new proc file (as a separate topic)?
Again, greatly appreciated.
Best, YJ
On Thu, 08 Sep 2022 12:32:14 +0200, YJ Lee wrote:
On Thu, Sep 8, 2022 at 4:16 PM Takashi Iwai tiwai@suse.de wrote:
On Thu, 08 Sep 2022 07:26:02 +0200, YJ Lee wrote:
Hello Takashi (and the alsa community),
This is YJ Lee from chromium.org.
I'm thinking about extending the ALSA dummy module to support customized volume leveling. It will be very useful to test devices with different volume granularity. Currently this module is using hard-coded mixer volume leveling, from min=-50 to max=100.
See L716: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/t...
My plan (A) is to expose 2 more additional module parameters and replace a few occurrences, from L742-750.
Another plan (B) is to leverage the current existing module parameter:model, and make the dummy-module to be able to accept models with customized volume leveling. New dummy models can be provided as configuration files, and be used in the same way as how currently existing dummy models (L146-213) are used. However, it's a bit over-engineering from the original purpose.
What do you think about these plans? Any insight you (and the alsa community) can provide will be greatly appreciated.
Only for volume min/max, module options may be an easier way, IMO.
OTOH, if we want to adjust more stuff, another possibility is to extend the proc file. It currently supports the dynamic changes of PCM parameters, but we can extend it or add a new proc file for adjusting other stuff, too. So the question is what else we want to allow changing.
thanks,
Takashi
Hi Takashi,
Thanks for your quick reply! I can't express my gratitude enough. Will stick with plan (A).
Additionally, I'll take some time to read it and learn how to use the proc file. Compared with snd-dummy, I've plugged in a physical USB headset and saw some read-only files (usb*) under /proc/asound/cardX. By extending the proc file, are you suggesting we can change those into writable so ALSA will understand and make corresponding changes, (e.g. 'change' the dummy card into a USB sound card)? Can you tell me more about how to extend or add a new proc file (as a separate topic)?
Some proc files allow writing, and the dummy driver's own proc file is such one (enabled only when CONFIG_SND_DEBUG=y, though). The proc file is created with snd_card_rw_proc_new() and the passed write callback is dummy_proc_write() in this case. It parses each text line and overrides the existing struct field accordingly.
HTH,
Takashi
On Thu, Sep 8, 2022 at 8:38 PM Takashi Iwai tiwai@suse.de wrote:
On Thu, 08 Sep 2022 12:32:14 +0200, YJ Lee wrote:
On Thu, Sep 8, 2022 at 4:16 PM Takashi Iwai tiwai@suse.de wrote:
On Thu, 08 Sep 2022 07:26:02 +0200, YJ Lee wrote:
Hello Takashi (and the alsa community),
This is YJ Lee from chromium.org.
I'm thinking about extending the ALSA dummy module to support customized volume leveling. It will be very useful to test devices with different volume granularity. Currently this module is using hard-coded mixer volume leveling, from min=-50 to max=100.
See L716: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/t...
My plan (A) is to expose 2 more additional module parameters and replace a few occurrences, from L742-750.
Another plan (B) is to leverage the current existing module parameter:model, and make the dummy-module to be able to accept models with customized volume leveling. New dummy models can be provided as configuration files, and be used in the same way as how currently existing dummy models (L146-213) are used. However, it's a bit over-engineering from the original purpose.
What do you think about these plans? Any insight you (and the alsa community) can provide will be greatly appreciated.
Only for volume min/max, module options may be an easier way, IMO.
OTOH, if we want to adjust more stuff, another possibility is to extend the proc file. It currently supports the dynamic changes of PCM parameters, but we can extend it or add a new proc file for adjusting other stuff, too. So the question is what else we want to allow changing.
thanks,
Takashi
Hi Takashi,
Thanks for your quick reply! I can't express my gratitude enough. Will stick with plan (A).
Additionally, I'll take some time to read it and learn how to use the proc file. Compared with snd-dummy, I've plugged in a physical USB headset and saw some read-only files (usb*) under /proc/asound/cardX. By extending the proc file, are you suggesting we can change those into writable so ALSA will understand and make corresponding changes, (e.g. 'change' the dummy card into a USB sound card)? Can you tell me more about how to extend or add a new proc file (as a separate topic)?
Some proc files allow writing, and the dummy driver's own proc file is such one (enabled only when CONFIG_SND_DEBUG=y, though). The proc file is created with snd_card_rw_proc_new() and the passed write callback is dummy_proc_write() in this case. It parses each text line and overrides the existing struct field accordingly.
HTH,
Takashi
Hi Takashi,
This greatly helps! Thanks so much for your kind explanation : )
Best, YJ
participants (2)
-
Takashi Iwai -
YJ Lee