[alsa-devel] Audio mini conference 2014?

[Takashi Iwai]

At Mon, 18 Aug 2014 10:33:31 +0200,
Daniel Mack wrote:
> 
> On 08/18/2014 10:25 AM, Lars-Peter Clausen wrote:
> > On 08/18/2014 10:15 AM, Takashi Iwai wrote:
> >> At Sun, 17 Aug 2014 18:10:21 -0500,
> >> Mark Brown wrote:
> 
> >>> I don't mind which option we go with, should I carry on or should I tell
> >>> her we'll go with ChaosDorf?
> >>
> >> Well, speaking of my preference, staying in the same location (the
> >> conference center) would be more practical.  But I don't mind much
> >> either.
> > 
> > Yea, from a logistics point of view it would be nice to keep it in the same 
> > location. On the other hand it doesn't seem to be that far away: 
> > https://goo.gl/maps/ax9Oi
> 
> Sure, logistically, it might indeed be better of course, and it wouldn't
> be a problem to cancel the ChaosDorf thing I guess - it's still two
> month in advance.
> 
> Let me know when we have a confirmed room at the conference venue, then
> I can let the ChaosDorf people know.

So we've set the schedule?  Mark, did you get the final confirmation?

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.


thanks,

Takashi

===

- 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?

- 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.