[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