From: pl bossart <bossart.nospam@gmail.com>
To: alsa-devel@alsa-project.org, Takashi Iwai <tiwai@suse.de>,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: ALSA and MediaController
Date: Tue, 17 May 2011 12:48:59 -0500 [thread overview]
Message-ID: <BANLkTikWAZAh-1Bm=8n0=2-fJjnA6R4mrw@mail.gmail.com> (raw)
During the ALSA/Embedded audio workshop two weeks ago we talked about
using the MediaController API (merged in 2.6.39) to provide userspace
with a graph-like representation of the transforms implemented in
firmware or hardware.
Two main applications were mentioned:
- volume control, at the moment in PulseAudio we get a flat list of
volume controls and we use a convoluted mixer logic to figure out if
'pcm playback volume' is done before or after 'master playback
volume'.
- tuning applications. With literally dozens of controls exposed in
embedded solutions, a flat list is going to be very hard to use. It
would make sense during the device tuning steps to figure out which
controls is located where to better understand its impacts. This would
help create UCM configuration files as well.
At the moment the Media Controller does not provide means to set any
values/parameters in a media_entity. We would need to cross-reference
each media_entity with ALSA controls and use the existing control
get/set interfaces. This raises 2 main questions:
- Is the list of ALSA controls is completely defined after the card
initialization step? Or do we have cases where ALSA controls are
created dynamically after the init? I tend to believe the former is
true but want to verify this with others on the mailing list. It's my
understanding that only connections may be changed in such a graph.
- Laurent suggested a new ioctl to export media_entity information to
userspace, as a binary buffer containing a list of TLV
(Type-Length-Value) field. However it looks like there's already an
ELEM_BYTES control type. It might make more sense to expose this
information using native ALSA controls, but again feedback from smart
people on this list would be welcome.
Thanks,
-Pierre
next reply other threads:[~2011-05-17 17:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-17 17:48 pl bossart [this message]
2011-05-17 18:02 ` ALSA and MediaController Mark Brown
2011-05-17 18:06 ` Takashi Iwai
2011-05-17 18:43 ` Takashi Iwai
2011-05-17 20:57 ` Mark Brown
2011-05-21 2:43 ` Raymond Yau
2011-05-21 10:57 ` Mark Brown
2011-05-23 5:39 ` Raymond Yau
2011-05-23 15:00 ` Mark Brown
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='BANLkTikWAZAh-1Bm=8n0=2-fJjnA6R4mrw@mail.gmail.com' \
--to=bossart.nospam@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=tiwai@suse.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;
as well as URLs for NNTP newsgroup(s).