[alsa-devel] Audio Miniconference 2013 schedule - Edinburgh 21st October
The audio mini-summit in Edinburgh is now less than a month away so it seems like a good time to start pulling together a schedule. Looking at the topics people mentioned when filling out the registration form there were three major topics that people wanted to cover:
- Compressed audio review: tinycompress, integration into userspace, driver upstreaming.
- UCM and other use case management status & review.
- Effects offload to DSPs with dynamically instantiatable algorithms, and general dynamic DSP firmware handling.
Plus a few things that only one or two people brought up:
- Process stuff (the list, bug tracking and so on).
- Some relatively specific hardware support topics: - HDMI hotplug handling throughout the stack - Mic status LED handling throughout the stack.
- Code cleanups: - Moving away from the custom ALSA device registration infrastructure. - General code modernisation.
- General routing control in userspace - UIs, automation.
The first question is if there is anything important that is missing from the above list - please speak up soon if there is! It'd also be good to have volunteers to lead the discussions in each area.
In terms of format I'd propose that we go through the list above in roughly that order, having someone lead discussion on the topic. Does this sound good to people?
As previously mentioned it'd be good if anyone planning to attend could fill in the form at:
https://docs.google.com/forms/d/105uav9tkwwkDU4P1T3IOWjfsa3kgtDbFAJOlHgBQR5k...
to help with planning & coordination.
On 03.10.2013 20:17, Mark Brown wrote:
The audio mini-summit in Edinburgh is now less than a month away so it seems like a good time to start pulling together a schedule. Looking at the topics people mentioned when filling out the registration form there were three major topics that people wanted to cover:
- Compressed audio review: tinycompress, integration into
userspace, driver upstreaming.
UCM and other use case management status & review.
Effects offload to DSPs with dynamically instantiatable
algorithms, and general dynamic DSP firmware handling.
- The status of DPCM and where we want to go with it. I think that's a very interesting and important yet fairly undocumented feature that not even the original authors seem to fully understand anymore ;)
Daniel
On Fri, 2013-10-04 at 12:04 +0200, Daniel Mack wrote:
On 03.10.2013 20:17, Mark Brown wrote:
The audio mini-summit in Edinburgh is now less than a month away so it seems like a good time to start pulling together a schedule. Looking at the topics people mentioned when filling out the registration form there were three major topics that people wanted to cover:
- Compressed audio review: tinycompress, integration into
userspace, driver upstreaming.
UCM and other use case management status & review.
Effects offload to DSPs with dynamically instantiatable
algorithms, and general dynamic DSP firmware handling.
- The status of DPCM and where we want to go with it. I think that's a
very interesting and important yet fairly undocumented feature that not even the original authors seem to fully understand anymore ;)
Fwiw, I've posted some recent patches to ASoC docs that include DPCM amongst other updates :) I'll also bring along some DPCM slides for Edinburgh too.
DSP FW handling and effects are important topics for me this year. I do have some patches for FW handling that have mostly been updated from the initial alsa-devel patch review (sadly from last December when I was at TI) and I plan to send for review V2 when HSW DSP driver is upstream.
Liam
--------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
On Fri, Oct 04, 2013 at 12:04:53PM +0200, Daniel Mack wrote:
- The status of DPCM and where we want to go with it. I think that's a
very interesting and important yet fairly undocumented feature that not even the original authors seem to fully understand anymore ;)
I think the main thing we need here is just someone to mainline drivers so we've got examples - I don't recall any particular confusion anyway. But yes, a status update would be good.
- Effects offload to DSPs with dynamically instantiatable algorithms, and general dynamic DSP firmware handling.
I can try and prepare an overview about what we've started to look at for effect offload. The one thing that's missing from the agenda is that DSP offload and dynamic firmware handling do require control on audio policy (high level arbitration between use cases), audio routing (some paths may not be available at all times) and resource management (memory/MCPS/etc). We not be able to solve this in a generic manner but having hooks to detect/notify a DSP resource is or is not available might be a good thing. -Pierre
On Fri, Oct 04, 2013 at 04:37:01PM -0500, Pierre-Louis Bossart wrote:
- Effects offload to DSPs with dynamically instantiatable algorithms, and general dynamic DSP firmware handling.
I can try and prepare an overview about what we've started to look at for effect offload. The one thing that's missing from the agenda
Thanks, that'd be great.
is that DSP offload and dynamic firmware handling do require control on audio policy (high level arbitration between use cases), audio routing (some paths may not be available at all times) and resource management (memory/MCPS/etc). We not be able to solve this in a generic manner but having hooks to detect/notify a DSP resource is or is not available might be a good thing.
Yes, all that stuff needs covering - I think I was trying to include that with "dynamic DSP firmware handling" but it really isn't at all clear.
On Fri, 2013-10-04 at 16:37 -0500, Pierre-Louis Bossart wrote:
- Effects offload to DSPs with dynamically instantiatable algorithms, and general dynamic DSP firmware handling.
I can try and prepare an overview about what we've started to look at for effect offload. The one thing that's missing from the agenda is that DSP offload and dynamic firmware handling do require control on audio policy (high level arbitration between use cases), audio routing (some paths may not be available at all times) and resource management (memory/MCPS/etc). We not be able to solve this in a generic manner but having hooks to detect/notify a DSP resource is or is not available might be a good thing.
Perhaps I should present our (Murphy[1] team at Intel) plans for the routing infrastructure and policy in PulseAudio? It might be relevant for this, although effect offloading and firmware handling is not something that we have thought about. Even without effect offloading and firmware handling the routing system has to deal with use case prioritizing and constraints regarding what audio paths are available and what paths can be used simultaneously.
BTW, there will also be a Murphy meeting/BoF on Wednesday at 13:00 in the Dunvegan room at the Sheraton hotel next to the conference center. Anyone who's interested in Murphy is welcome to attend. I'd expect there to be a general overview of Murphy from Janos, and I should present the status and plans for the routing work in PulseAudio (perhaps in more detail than in the audio miniconf). Other than that, there's not much else planned, just general Q&A with the Murphy developers (Janos Kovacs and Jaska Uimonen will be present - too bad they couldn't make it to the audio miniconf).
[1] Murphy is the resource policy daemon in Tizen IVI, https://01.org/murphy/
On Sun, Oct 06, 2013 at 07:10:59PM +0300, Tanu Kaskinen wrote:
Perhaps I should present our (Murphy[1] team at Intel) plans for the routing infrastructure and policy in PulseAudio? It might be relevant for this, although effect offloading and firmware handling is not something that we have thought about. Even without effect offloading and firmware handling the routing system has to deal with use case prioritizing and constraints regarding what audio paths are available and what paths can be used simultaneously.
That sounds interesting, there was also a use case management thing on the agenda - do you want to take that? It'd be better if the presentation bits could be minimised so that most of the time is given over to discussion.
BTW, there will also be a Murphy meeting/BoF on Wednesday at 13:00 in the Dunvegan room at the Sheraton hotel next to the conference center. Anyone who's interested in Murphy is welcome to attend. I'd expect there to be a general overview of Murphy from Janos, and I should present the status and plans for the routing work in PulseAudio (perhaps in more detail than in the audio miniconf). Other than that, there's not much else planned, just general Q&A with the Murphy developers (Janos Kovacs and Jaska Uimonen will be present - too bad they couldn't make it to the audio miniconf).
That'd be interesting too, though the ARM stuff is on the Wednesday so I'm not entirely sure if I'll be able to make it sadly :( .
On Mon, 2013-10-07 at 16:14 +0100, Mark Brown wrote:
On Sun, Oct 06, 2013 at 07:10:59PM +0300, Tanu Kaskinen wrote:
Perhaps I should present our (Murphy[1] team at Intel) plans for the routing infrastructure and policy in PulseAudio? It might be relevant for this, although effect offloading and firmware handling is not something that we have thought about. Even without effect offloading and firmware handling the routing system has to deal with use case prioritizing and constraints regarding what audio paths are available and what paths can be used simultaneously.
That sounds interesting, there was also a use case management thing on the agenda - do you want to take that?
Sure, why not.
On 10/03/2013 08:17 PM, Mark Brown wrote:
The audio mini-summit in Edinburgh is now less than a month away so it seems like a good time to start pulling together a schedule. Looking at the topics people mentioned when filling out the registration form there were three major topics that people wanted to cover:
Compressed audio review: tinycompress, integration into userspace, driver upstreaming.
UCM and other use case management status & review.
Effects offload to DSPs with dynamically instantiatable algorithms, and general dynamic DSP firmware handling.
Plus a few things that only one or two people brought up:
Process stuff (the list, bug tracking and so on).
Some relatively specific hardware support topics:
HDMI hotplug handling throughout the stack
Mic status LED handling throughout the stack.
Code cleanups:
Moving away from the custom ALSA device registration infrastructure.
General code modernisation.
General routing control in userspace - UIs, automation.
The first question is if there is anything important that is missing from the above list - please speak up soon if there is! It'd also be good to have volunteers to lead the discussions in each area.
One thing I think that would be good to discuss, considering how often this has come up over the last few months, is devicetree bindings for audio devices. And what should and needs to be done on the framework side to better support this.
- Lars
On Mon, Oct 07, 2013 at 06:39:48PM +0200, Lars-Peter Clausen wrote:
One thing I think that would be good to discuss, considering how often this has come up over the last few months, is devicetree bindings for audio devices. And what should and needs to be done on the framework side to better support this.
There's going to be a *very* large segment of the ARM mini-summit given over to device tree discussions, it seems better to cover that there since this is an issue that affects a bunch of subsystems in similar ways.
On 10/3/2013 11:17 AM, Mark Brown wrote:
The first question is if there is anything important that is missing from the above list - please speak up soon if there is!
Lately, there has been a lot of emphasis on reducing cold start latency which audio hardware path setup takes up good chunk of time. I found DAPM takes up quite a bit of time finding path to enable. In addition, DPCM could be enhanced to save on cold start latency by enabling front-end & back-end in parallel if underlying hardware can support it.
I would like to see if we can have some discussion on optimization.
Thanks Patrick
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Mon, Oct 07, 2013 at 10:22:42AM -0700, Patrick Lai wrote:
Lately, there has been a lot of emphasis on reducing cold start latency which audio hardware path setup takes up good chunk of time. I found DAPM takes up quite a bit of time finding path to enable. In addition,
What are the problems you're seeing here? This used to be a big problem for modern CODECs with big sets of widgets and routes but the optimisations I did a while back (which made it into v3.4 so I think everyone is using them now) and the work that Tsutsui-san did in v3.10 on improving the graph reset got it reasonably under control for the systems that I was aware of having trouble.
The commits from Tsutsui-san were:
0e669246dcd1 ASoC: dapm: Remove redundant clear_walk() for supply widgets 1059ecfa0f1e ASoC: dapm: Only clear paths we've walked
(mainly the second one).
DPCM could be enhanced to save on cold start latency by enabling front-end & back-end in parallel if underlying hardware can support it.
Hrm, nobody mentioned any problems with CPU side startup times previously. What exactly is taking the time with this stuff - is it something that could be pushed into DAPM and use what's there already (or alternatively then be optimised and used for CODECs too)?
I would like to see if we can have some discussion on optimization.
Well volunteered :)
On Mon, Oct 07, 2013 at 06:44:48PM +0100, Mark Brown wrote:
What are the problems you're seeing here? This used to be a big problem for modern CODECs with big sets of widgets and routes but the optimisations I did a while back (which made it into v3.4 so I think everyone is using them now) and the work that Tsutsui-san did in v3.10 on improving the graph reset got it reasonably under control for the systems that I was aware of having trouble.
I did think of one area that might be usefully improved here - we currently don't do async I/O for any of the DAPM generated writes. It's not going to be anything too massive but for faster buses like SPI or Slimbus it should deliver something.
This would require an annoying amount of plumbing in regmap to pass flags around but might be worth it for faster buses. The core I/O code is fine with it but the abstraction to allow buses to hook in at the register read/write level makes this more annoying a refactoring than I'd like while we've got all the ASoC conversions to regmap in progress.
participants (8)
-
Daniel Mack -
Lars-Peter Clausen -
Liam Girdwood -
Mark Brown -
Patrick Lai -
Pierre-Louis Bossart -
Tanu Kaskinen -
Tanu Kaskinen