On Thu, Sep 8, 2022 at 8:38 PM Takashi Iwai <tiwai@xxxxxxx> 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@xxxxxxx> 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/tree/sound/drivers/dummy.c?h=queue/5.19#n716 > > > > > > > > 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
