From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: Tanjeff Moos <tanjeff@cccmz.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: How to identify Alsa eLements?
Date: Fri, 3 Jul 2020 17:53:34 +0900 [thread overview]
Message-ID: <20200703085334.GA9425@workstation> (raw)
In-Reply-To: <00efd9d1-8eef-fb06-d9bf-867ca37e2e74@cccmz.de>
On Fri, Jul 03, 2020 at 08:16:26AM +0200, Tanjeff Moos wrote:
> > Anyway, when using alsa-lib application for the purpose, you should pay
> > enough attention to which API is used since alsa-lib includes several
> > abstractions of API for control element set in each level:
> >
> > * Lower abstraction (snd_ctl_xxx)
> > * Higher abstraction (snd_hctl_xxx)
> > * Setup control interface (snd_sctl_xxx)
> > * Mixer interface (snd_mixer_xxx)
> > * Simple Mixer interface (snd_mixer_selem_xxx)
>
> I find this quite confusing. If I could change a volume control using any of
> those interfaces, then I don't understand when to use which interface. I'm
> sure that there is good reasoning for each of them, but unfortunatly the
> documentation has very little information about these concepts.
So do I. I can imagine that the toughness of work to design good
abstraction for the control feature...
> Anyway, I will stick to the lower abstraction which serves my needs. In the
> worst case I will do more work than necessary ;-)
>
> > The configuration space of alsa-lib affects Setup control interface
> > and Mixer interface. On the other hand, it doesn't affect the
> > lower/higher abstraction. The amixer is a kind of application to use
> > 'snd_hctl_xxx', 'snd_mixer_xxx', and 'snd_mixer_selem_xxx'.
>
> So the controls offered by CTL/HCTL are determined by the driver? And SCTL,
> MIXER and MIXER_SELEM are influenced by user space config files?
Yes, as long as I know.
HCTL abstraction nearly equals to 'CTL + cache mechanism for control elements +
event notification callback'. However in some cases of addition/removal control
element set from user space[1], it hits assert and aborts programs with
panic.
SCTL/MIXER/MIXER_SELEM features includes extra filter logic for control
elements with the configuration. They're specialized to usual channel of
audio; e.g. stereo, surround sounds. It's functional as long as using usual
sound devices such as stereo speakers. On the other hand, they can handle
just a part of the channels when handling control elements for exceptional
multi-channel of audio for recording equipments. I guess that your case
is the latter.
> > When you'd like to communicate to kernel land implementation without any
> > effects of alsa-lib's configuration space. it's better to use the lower/higher
> > abstractions. As long as I've used, 'qashctl' in QasTools[4] is good GUI
> > application for this purpose. It's written with Qt5 and seems to be helpful
> > for your work in both of GUI programming and control elements handling.
> qashctl is indeed very helpful, thank you! As being said, I'll stick to CTL.
>
> Thank you very much for your advice!
Quashctl is pretty good tool for the purpose as long as I know. I wish for
someone to develop similar functional tool with CUI or TUI...
[1] for example, below test program can abort pulseaudio when removing
added control element set:
https://github.com/alsa-project/alsa-lib/blob/master/test/user-ctl-element-set.c
Regards
Takashi Sakamoto
prev parent reply other threads:[~2020-07-03 8:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-02 20:05 How to identify Alsa eLements? Tanjeff Moos
2020-07-03 0:34 ` Takashi Sakamoto
2020-07-03 0:48 ` Takashi Sakamoto
2020-07-03 6:16 ` Tanjeff Moos
2020-07-03 8:53 ` Takashi Sakamoto [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200703085334.GA9425@workstation \
--to=o-takashi@sakamocchi.jp \
--cc=alsa-devel@alsa-project.org \
--cc=tanjeff@cccmz.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox