Audio Miniconference 2013 schedule - Edinburgh 21st October

Audio Miniconference 2013 schedule - Edinburgh 21st October

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1616 bytes --]

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/viewform

to help with planning & coordination.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Audio Miniconference 2013 schedule - Edinburgh 21st October

[Daniel Mack]

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

Re: Audio Miniconference 2013 schedule - Edinburgh 21st October

[Liam Girdwood]

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.

Re: Audio Miniconference 2013 schedule - Edinburgh 21st October

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 458 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Audio Miniconference 2013 schedule - Edinburgh 21st October

[Pierre-Louis Bossart]

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

Re: Audio Miniconference 2013 schedule - Edinburgh 21st October

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 898 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Audio Miniconference 2013 schedule - Edinburgh 21st October

[Tanu Kaskinen]

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/

-- 
Tanu

Re: Audio Miniconference 2013 schedule - Edinburgh 21st October

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1495 bytes --]

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

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Audio Miniconference 2013 schedule - Edinburgh 21st October

[Tanu Kaskinen]

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.

-- 
Tanu

Re: Audio Miniconference 2013 schedule - Edinburgh 21st October

[Lars-Peter Clausen]

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

Re: Audio Miniconference 2013 schedule - Edinburgh 21st October

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 533 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Audio Miniconference 2013 schedule - Edinburgh 21st October

[Patrick Lai]

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
>


-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Audio Miniconference 2013 schedule - Edinburgh 21st October

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1398 bytes --]

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 :)

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Audio Miniconference 2013 schedule - Edinburgh 21st October

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1061 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]