14.07.2015 21:17, Mark Brown wrote:

On Tue, Jul 14, 2015 at 09:04:30PM +0500, Alexander E. Patrakov wrote:

...

I would like to see some direct measurements related to recent power-saving proposals, including the "disable rewinds" flag. Myself, I can redo battery-life measurements on Intel-based laptops that my colleagues have, and maybe compare dmix, PulseAudio and CRAS in terms of power consumption.

The numbers I seem to remember seeing at the time were these IIRC:

http://linux-tipps.blogspot.co.uk/2011/04/power-performance-of-pulseaudio-alsa.html

saying there was a 0.4W win (I think Arun had some similar numbers).

Thanks for the link. I have no reason to doubt these measurements. Note, however, that they are of the "pulseaudio vs pulseaudio" type, and give no insight into the structure of the win. By "structure", I mean the proportion of energy wasted due to the wakeup itself, in the kernel code, and in the pulseaudio code. IOW, they, technically, don't rule out the "pulseaudio is inefficient at low latencies, and that's pulseaudio's fault" possibility. That's why (and also because, on my hardware, the win with hw:0 and aplay is smaller) I want to do some cross-comparisons of various sound servers to the raw hw:0 device. It would also be nice to be able to see directly the effect of David's work on srbchannel.

On 7/14/15 11:04 AM, Alexander E. Patrakov wrote:

14.07.2015 20:03, Mark Brown wrote:

...

Like previous years, we're going to hold a meeting to discuss lowlevel audio on Linux. This will be held the day after ELC Europe on 8th October at CCD (The Convention Centre) in Dublin.

If you're interested please sign up in the attendee list:

https://docs.google.com/spreadsheets/d/1bi-8GHsqlzt41FR20WiMuWILe_cZowFireVM...

and please follow up to this mail with any topics you'd like to see raised so we can start collecting them (probably another Google doc will be forthcoming for them).

I would like to see some direct measurements related to recent power-saving proposals, including the "disable rewinds" flag. Myself, I can redo battery-life measurements on Intel-based laptops that my colleagues have, and maybe compare dmix, PulseAudio and CRAS in terms of power consumption.

Ideally, I would like to reevaluate the design decisions (namely, the need to keep the system responsive to new streams while keeping the average wakeup rate as low as possible, IMHO even to the point of "absurdly low") that led to the need to support rewinds (and the associated complexity) in the first place. Reminder: on my Sony VAIO VPC-Z23A4R laptop and hw:0 device, in an unrealistic test with the screen turned off, wi-fi turned off, and the SSDs put to sleep, going from 200 to 1 wakeup per second saved only 935 seconds of battery life out of 25742.

I had more success that you in my experiments a long time ago, but this really depends on what the rest of the system does. You have a point though that we should talk about design decisions for userspace code. The current PulseAudio implementation lags behind the capabilities of newer devices with two or more outputs (low-latency, increased buffering and hardware/firmware mixing). This should really be a topic following the presentation of the HDAudio/Asoc restructuring that Vinod mentioned (i.e. how to change userspace code to support driver capabilities). -Pierre

Hi,

Is registration to ELCE mandatory to attend the audio mini summit this year or not?

Thanks.

Eric.

On Sat, Jul 18, 2015 at 10:07 AM, Vinod Koul vinod.koul@intel.com wrote:

On Tue, Jul 14, 2015 at 04:03:52PM +0100, Mark Brown wrote:

...

Like previous years, we're going to hold a meeting to discuss lowlevel audio on Linux. This will be held the day after ELC Europe on 8th October at CCD (The Convention Centre) in Dublin.

If you're interested please sign up in the attendee list:

https://docs.google.com/spreadsheets/d/1bi-8GHsqlzt41FR20WiMuWILe_cZowFireVM...

...

and please follow up to this mail with any topics you'd like to see raised so we can start collecting them (probably another Google doc will be forthcoming for them).

Previously suggested topics include:

• Reducing kernel size for IoT applications
• ACPI simple-card
• Testing tools

I would like to have following added as well

• Recent & ongoing HDA restructuring. Hopefully by that time we should have all the pieces sorted out and shipping systems. So a good discussion and feedback...
• HDMI interfaces, maybe we can get someone from gfx side as well. Recently [1] we discussed additional interfaces to make things robust
• Topology.
• PCM core. What can we do to simplify this code which seems very scary :)

Also I have not seen much traction on this and last announcement, so I took the liberty to CC attendees from last year

Thanks

~Vinod

OK. Should be fine, I will be able to use one of google invites.

Thanks.

On Mon, Sep 14, 2015 at 11:02 AM, Mark Brown broonie@kernel.org wrote:

On Thu, Sep 10, 2015 at 02:35:07PM -0700, Eric Laurent wrote:

...

Is registration to ELCE mandatory to attend the audio mini summit this

year

...

or not?

I believe so, yes - let me know if this is going to be an issue and I'll see what we can do.

On 7/21/15 6:29 AM, Bard Liao wrote:

...

-----Original Message----- From: Mark Brown [mailto:broonie@kernel.org] Sent: Tuesday, July 14, 2015 11:04 PM To: Takashi Iwai; Liam Girdwood; Jaroslav Kysela Cc: alsa-devel@alsa-project.org Subject: [REANNOUNCE] Audio Mini Summit 2015, 8th October, Dublin

Like previous years, we're going to hold a meeting to discuss lowlevel audio on Linux. This will be held the day after ELC Europe on 8th October at CCD (The Convention Centre) in Dublin.

If you're interested please sign up in the attendee list:

https://docs.google.com/spreadsheets/d/1bi-8GHsqlzt41FR20WiMuWILe_ cZowFireVMBd-QM8Q/edit?usp=sharing

and please follow up to this mail with any topics you'd like to see raised so we can start collecting them (probably another Google doc will be forthcoming for them).

Previously suggested topics include:

• Reducing kernel size for IoT applications
• ACPI simple-card

I think we should also share findings on DeviceTree vs. ACPI support for machine drivers and subnodes.

...

• Testing tools

Could we also discuss the driver support for MIPI SoundWire ?

Yes we should. This might require additional time or a dedicated session though.

Is there any existing code in kernel using MIPI SoundWire?

Not yet, this is work-in-progress. Note that a list of device properties has already been defined and is available to MIPI contributors, it'll be released more widely at some point.

...

Thanks, Mark

------Please consider the environment before printing this e-mail.

---

Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

On 3 August 2015 at 08:45, Vinod Koul vinod.koul@intel.com wrote:

On Mon, Jul 27, 2015 at 06:05:15PM -0500, Pierre-Louis Bossart wrote:

...

On 7/21/15 6:29 AM, Bard Liao wrote:

...

...

-----Original Message----- From: Mark Brown [mailto:broonie@kernel.org] Sent: Tuesday, July 14, 2015 11:04 PM To: Takashi Iwai; Liam Girdwood; Jaroslav Kysela Cc: alsa-devel@alsa-project.org Subject: [REANNOUNCE] Audio Mini Summit 2015, 8th October, Dublin

Like previous years, we're going to hold a meeting to discuss lowlevel audio on Linux. This will be held the day after ELC Europe on 8th October at CCD (The Convention Centre) in Dublin.

If you're interested please sign up in the attendee list:

https://docs.google.com/spreadsheets/d/1bi-8GHsqlzt41FR20WiMuWILe_ cZowFireVMBd-QM8Q/edit?usp=sharing

and please follow up to this mail with any topics you'd like to see raised so we can start collecting them (probably another Google doc will be forthcoming for them).

Previously suggested topics include:

• Reducing kernel size for IoT applications
• ACPI simple-card

I think we should also share findings on DeviceTree vs. ACPI support for machine drivers and subnodes.

I am planning to discuss two things in this space:

• One the NHLT table in BIOS
• Second my ongoing work on ACPI properties for machines, hopefully should be able to send patches before conference

I have a a couple of things to add:

1. The BATCH flag, granularity, etc. again (this is really biting us with USB devices since we're respecting it)

2. Some work I've been doing on configuration (not the consolidation we were looking for at the end of last meeting, but something I should be able to send a link to here in a week or two)

Cheers, Arun

On Sat, Oct 03, 2015 at 06:13:26PM +0200, Takashi Iwai wrote:

Mark, do you have a list of topics available on net, e.g. via google doc?

Not yet, though it's basically only a couple of e-mails to collate at this point.

Hi again, all,

On 22 September 2015 at 14:19, Arun Raghavan arun@accosted.net wrote:

On 3 August 2015 at 08:45, Vinod Koul vinod.koul@intel.com wrote:

...

On Mon, Jul 27, 2015 at 06:05:15PM -0500, Pierre-Louis Bossart wrote:

...

On 7/21/15 6:29 AM, Bard Liao wrote:

...

...

-----Original Message----- From: Mark Brown [mailto:broonie@kernel.org] Sent: Tuesday, July 14, 2015 11:04 PM To: Takashi Iwai; Liam Girdwood; Jaroslav Kysela Cc: alsa-devel@alsa-project.org Subject: [REANNOUNCE] Audio Mini Summit 2015, 8th October, Dublin

Like previous years, we're going to hold a meeting to discuss lowlevel audio on Linux. This will be held the day after ELC Europe on 8th October at CCD (The Convention Centre) in Dublin.

If you're interested please sign up in the attendee list:

https://docs.google.com/spreadsheets/d/1bi-8GHsqlzt41FR20WiMuWILe_ cZowFireVMBd-QM8Q/edit?usp=sharing

and please follow up to this mail with any topics you'd like to see raised so we can start collecting them (probably another Google doc will be forthcoming for them).

Previously suggested topics include:

• Reducing kernel size for IoT applications
• ACPI simple-card

I think we should also share findings on DeviceTree vs. ACPI support for machine drivers and subnodes.

I am planning to discuss two things in this space:

• One the NHLT table in BIOS
• Second my ongoing work on ACPI properties for machines, hopefully should be able to send patches before conference

I have a a couple of things to add:

1. The BATCH flag, granularity, etc. again (this is really biting us

with USB devices since we're respecting it)

2. Some work I've been doing on configuration (not the consolidation

we were looking for at the end of last meeting, but something I should be able to send a link to here in a week or two)

I was hoping to get just a bit more done before sending this out, but there's not much time left before the audio meetup. I've been working on a tool to make it a bit easier to translate Android XML configuration to UCM. It's up at:

https://github.com/ford-prefect/xml2ucm

The idea is to take the mixer_paths.xml, write a bit of extra configuration as a separate file describing devices, use cases, etc. and then have UCM output from that. You can see some example configuration for the Sony Xperia Z3 Compact (aries) at:

https://github.com/ford-prefect/xml2ucm/blob/master/examples/aries-l-config.... https://github.com/ford-prefect/xml2ucm/blob/master/examples/aries-l-mixer_p...

That particular configuration works fine for HiFi. I was hoping to get the voice call config also done by now, but it's been a bit uphill since I'm working without any specs.

I'm happy to hear feedback on whether this is useful, what else you'd like to see if it is, and anything else you might have comments on.

Cheers, Arun

p.s.: Yes, it's in Haskell, sorry about the added pain there. I'm planning on having this also available as a simple web service so you don't have to build it to use it (the README should have accurate documentation on how to build, though).

On Sat, Aug 01, 2015 at 09:37:16AM +0200, Lars-Peter Clausen wrote:

On 07/14/2015 05:03 PM, Mark Brown wrote:

...

[...]

and please follow up to this mail with any topics you'd like to see raised so we can start collecting them (probably another Google doc will be forthcoming for them).

Full media controller integration for both ALSA and ASoC. How this can be used to export topology information to userspace and how to for example attach a specific volume control to a specific media controller entity. And maybe also how to de-duplicate similar functionality between DAPM and media controller.

The recently merged topology core allows us to 'send' the complete topology information for a component to kernel drivers.

So with this we now we have two additional choices: - assuming all components use topology framework, we don't need to query, we use the topology information available in usermode. Some more support to parse topology binary installed and show as controls in alsa-lib might be required here - do a reverse path, based on dapm and control info (driver will need to add code for linking the two) we add a new reverse API, which tells us the topology information from kernel

On Tue, Aug 04, 2015 at 05:13:35PM +0100, Mark Brown wrote:

On Mon, Aug 03, 2015 at 08:51:28AM +0530, Vinod Koul wrote:

...

On Sat, Aug 01, 2015 at 09:37:16AM +0200, Lars-Peter Clausen wrote:

...

...

Full media controller integration for both ALSA and ASoC. How this can be used to export topology information to userspace and how to for example attach a specific volume control to a specific media controller entity. And maybe also how to de-duplicate similar functionality between DAPM and media controller.

...

The recently merged topology core allows us to 'send' the complete topology information for a component to kernel drivers.

...

So with this we now we have two additional choices:

• assuming all components use topology framework, we don't need to query, we use the topology information available in usermode. Some more support to parse topology binary installed and show as controls in alsa-lib might be required here

That'd require us to move all the DAPM information for drivers out of the kernel and into userspace which seems a bit worrying - it's going to be harder for things that need events and I worry about the effect on quality of implementation if people stop sending things to get reviewed.

Not for this option, for example in SKL.

kernel doesnt have toplogy information coded in, it is parsed and build from topology binary which is built by alsa-lib. So if we add more alsa-lib APIs to parse the installed binary we have good view of system without going to kernel, we know complete graph and controls...

...

• do a reverse path, based on dapm and control info (driver will need to add code for linking the two) we add a new reverse API, which tells us the topology information from kernel

That's basically what the media controller API discussion has been.

Yes lets discuss more during the conf...

Full media controller integration for both ALSA and ASoC. How this can be used to export topology information to userspace and how to for example attach a specific volume control to a specific media controller entity. And maybe also how to de-duplicate similar functionality between DAPM and media controller.

This is something I looked at, without much progress though beyond a set of initial patches to make use of the media controller API. There were two issues: - one was to agree on a syntax/format for the (binary) topology information exposed by the kernel. - the main issue was really how to link a user-visible volume slider to a specific or group of volume controls. A number of people have tried this before in other contexts and it's really hard to do based on topology information only.

But yes a good topic to re-discuss -Pierre

On 08/04/2015 06:03 PM, Mark Brown wrote:

On Sat, Aug 01, 2015 at 09:37:16AM +0200, Lars-Peter Clausen wrote:

...

On 07/14/2015 05:03 PM, Mark Brown wrote:

...

...

and please follow up to this mail with any topics you'd like to see raised so we can start collecting them (probably another Google doc will be forthcoming for them).

...

Full media controller integration for both ALSA and ASoC. How this can be used to export topology information to userspace and how to for example attach a specific volume control to a specific media controller entity. And maybe also how to de-duplicate similar functionality between DAPM and media controller.

We keep talking about this but it never goes anywhere. I think everyone agrees that in principal it's a good idea but nobody's actually taken the next step and started working on it. Do we think we're likely to come to any new conclusions here?

I hope to have some basic support ready by then.