About ALSA dummy module: support customized mixer volume leveling

[Takashi Iwai]

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