[alsa-devel] Audio mini conference 2014?
Takashi Iwai
tiwai at suse.de
Tue Aug 26 12:11:30 CEST 2014
At Tue, 26 Aug 2014 09:42:20 +0100,
Mark Brown wrote:
>
> On Tue, Aug 26, 2014 at 08:21:38AM +0200, Takashi Iwai wrote:
>
> > So we've set the schedule? Mark, did you get the final confirmation?
>
> No confirmation yet but then it was LinuxCon all last week - I'm
> expecting something this week.
OK, thanks.
> > FWIW, below is topics (and comments) I gathered from the thread. Just
> > edit over it and repost if anyone has an idea, correction or
> > suggestion.
>
> I don't know if it's also worth talking about mapping channels through
> DAI links in ASoC - I'm not sure anyone is intending to work on it in
> the immediate term so I'd suggest putting it on the end of the list as
> an "if we have time" kind of thing.
I put in the list.
> > - Code removals (Takashi)
> > There have been actions to remove the codes for old hardware
> > recently. Which is acceptable? Feature removals, too?
>
> Linus was muttering about ISA sound card drivers.
Interesting, I thought Linus doesn't mind much about such "dead"
drivers.
> > - tinyUCM (Mark?, Brian?)
> > The latest Google reference designs use something which is
> > essentially tinyucm - the configuration is mostly stored in an XML
> > configuration file which is read at runtime. It's not consistent
> > with what anyone else uses.
>
> > (Brian) Those must be the qcom designs. They use a “tinyucm" that is
> > xml based.
>
> IIRC Manta was using it as well, I think it was the first device to do
> so.
Below is the updated list.
Takashi
===
Audio Mini-Summit 2014 - Proposed Topics
- ASoC componentization (Lars)
- Dynamic FW (Vinod)
Me and Liam will try to send RFCs before the conference. At least on
my side thats next todo after current mrfld driver is done.
We have working code atm. For the folks who want to look at early
state of affairs, here are the trees:
Kernel: git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/sound.git dfw-3.15
Usermode: git://git.infradead.org/users/vkoul/dynamic_fw.git
- Effect API (yet again) (Vinod)
- More DSP support esp on PCM side (Vinod)
- Rewinding in ALSA PCM plugins (Alexander)
- Resampler quality evaluation for PulseAudio (Alexander)
- Testing / QA (Takashi)
How people do test? Can we have some automation?
(IIRC, openSUSE has some automatic audio test running on VM, but I
forgot the details...)
(Vinod) I would be interested in this as well, some test framework
for auto regression checks would be great.
I think Mark would be at KS and can update if we can leverage
something for kselftest stuff being discussed there
(Mark) Not really, it's more about standardising the way tests are
triggered and reported.
- Automated tests of HDA codec parser code (David)
I run automated tests of the HDA codec parser code and has done so
for quite a while now. Not much has happened the last year, but I
can talk about it if anyone is interested. (It's a test framework
around hda-emu.)
- ABI/API documentation (Takashi)
We're not good at this at all, obviously. Let's define the priority
to start working on.
(Vinod) I think ASoC has grown a lot with DPCM etc making it very
dynamic atm. So yes it will help to add more
- Control names (Takashi)
It's wild west for now, everyone picks up a random funky name.
(Vinod) yes, I think the current control names were too HDA
specific. With DSP and audio hub proliferation on SoCs/Codecs
revisiting this would certainly be great. Like how do I specify
volume control for gain before a mixer, or gain in capture BE which
is different from the one on capture FE.
- Code removals (Takashi)
There have been actions to remove the codes for old hardware
recently. Which is acceptable? Feature removals, too?
(Mark) Linus was muttering about ISA sound card drivers.
- Configuration convergence (Vinod)
From the OS side, we have Desktop OSes relying on PA, Chrome using
CRAS, Android using flinger. With DSPs and tons of configuration it
doesn't bode well to have multiple configuration for same stuff for
the sound cards. Can we talk about unifying the configuration at
least. Sure OSes will have their own ways to use, but from ALSA can
we standardize configurations which can be reused across.
(Takashi) I thought UCM was targeted to this, but not widely used as
expected?
(Mark) Right, the problems with alsa-lib licensing and the changes
in the configuration format have been a bit of a blocker - there are
actually some substantial deployments of the pre-merge configuration
file format.
- ChromeOS UCM usage (Dylan)
I'm giving a talk with an overview of ChromeOS's audio system at ELC
on Tuesday at 12:15, but aside from that I'll attend the whole day.
- tinyUCM (Mark?, Brian?)
The latest Google reference designs use something which is
essentially tinyucm - the configuration is mostly stored in an XML
configuration file which is read at runtime. It's not consistent
with what anyone else uses.
(Brian) Those must be the qcom designs. They use a “tinyucm" that is
xml based.
(Mark) IIRC Manta was using it as well, I think it was the first
device to do so.
- Mapping channels through DAI links in ASoC (Mark)
I'm not sure anyone is intending to work on it in the immediate term
so I'd suggest putting it on the end of the list as an "if we have
time" kind of thing.
More information about the Alsa-devel
mailing list