About ALSA dummy module: support customized mixer volume leveling

[YJ Lee]

On Thu, Sep 8, 2022 at 8:38 PM Takashi Iwai <tiwai at 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 at 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/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