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.