Plumbers: Please split audio topics into separate sessions

Plumbers: Please split audio topics into separate sessions

[David Henningsson]

Looking at:

http://summit.linuxplumbersconf.org/lpc-2012/track/lpc2012-audio/

45 minutes is not enough to handle two topics:

Audio uConf: HD-audio cooking && QA/Testing
Audio uConf: Expose Routing && DSPs in ASoC
Audio uConf: Time Alignment && PA on Android

Please split these three sessions into six. It is better to have a 
little more time than necessary (even if I believe we easily fill 45 
minutes per topic), than having to skip a topic just because the other 
topic took more time than expected.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: Plumbers: Please split audio topics into separate sessions

[Takashi Iwai]

At Mon, 06 Aug 2012 21:09:24 +0200,
David Henningsson wrote:
> 
> Looking at:
> 
> http://summit.linuxplumbersconf.org/lpc-2012/track/lpc2012-audio/
> 
> 45 minutes is not enough to handle two topics:
> 
> Audio uConf: HD-audio cooking && QA/Testing
> Audio uConf: Expose Routing && DSPs in ASoC
> Audio uConf: Time Alignment && PA on Android
> 
> Please split these three sessions into six. It is better to have a 
> little more time than necessary (even if I believe we easily fill 45 
> minutes per topic), than having to skip a topic just because the other 
> topic took more time than expected.

Well, as already announced, each topic was planned to be about 20
minutes, so I don't think we need to extend session time.
Skipping a topic can be avoided simply by looking at the clock, and
cut at 20 minutes.

Each topic isn't expected to be a big "show" at all.  We hope each the
topic leader shows a couple of slides at most to state the problem and
the possible solution, and then leads the discussions.  Plumbers is a
place to discuss the feature and the problem we are facing, not a
place to demonstrate the already existing solution.

Of course, it's possible to ask more slots, if you are sure that one
topic would need really 40 minutes discussions.

BTW, there is one more slot, planned for my topic for channel mapping
API.  This can be used also for the pending issues, for example.


thanks,

Takashi

Re: Plumbers: Please split audio topics into separate sessions

[David Henningsson]

On 08/06/2012 09:29 PM, Takashi Iwai wrote:
> At Mon, 06 Aug 2012 21:09:24 +0200,
> David Henningsson wrote:
>>
>> Looking at:
>>
>> http://summit.linuxplumbersconf.org/lpc-2012/track/lpc2012-audio/
>>
>> 45 minutes is not enough to handle two topics:
>>
>> Audio uConf: HD-audio cooking && QA/Testing
>> Audio uConf: Expose Routing && DSPs in ASoC
>> Audio uConf: Time Alignment && PA on Android
>>
>> Please split these three sessions into six. It is better to have a
>> little more time than necessary (even if I believe we easily fill 45
>> minutes per topic), than having to skip a topic just because the other
>> topic took more time than expected.
>
> Well, as already announced, each topic was planned to be about 20
> minutes, so I don't think we need to extend session time.

Judging from our last experience, where we had a two-hour session on 
Sunday and then had to reschedule on Wednesday for two more hours, and 
yet had to cancel the topic I was about to introduce, because everybody 
was tired (and waiting for lunch), I certainly beg to differ!

Besides, I don't remember seeing such a 20 minute announcement. But 
maybe I missed it.

> Skipping a topic can be avoided simply by looking at the clock, and
> cut at 20 minutes.

Given the talkative crowd that we are, that might not be so simple ;-)

> Each topic isn't expected to be a big "show" at all.  We hope each the
> topic leader shows a couple of slides at most to state the problem and
> the possible solution, and then leads the discussions.
> Of course, it's possible to ask more slots, if you are sure that one
> topic would need really 40 minutes discussions.

It's the discussions that take time.

Also all of the 45 minutes is not effective discussion/presentation 
time: Assume that we first wait 5 minutes for all people to appear, then 
we have 5 minutes presentation and 15 - 20 minutes discussion for the 
first topic, then 5 minutes are spent fiddling with the projector to 
show the slides for the second topic...and suddenly there is just a few 
minutes left for discussion of the second topic.

Maybe it can be done in 20 minutes in theory, and everything goes as 
planned, but it is very overly optimistic.

Also; we fly across half the world to get there, to spend just a few 
minutes talking? Better have some margins. Maybe some session will end 
early, but will it hurt? No. If we miss a topic, or have to cut it short 
without a conclusion, will it hurt? Yes.

> BTW, there is one more slot, planned for my topic for channel mapping
> API.  This can be used also for the pending issues, for example.

Given how the scheduler works - it tries to make sure required 
participants are not scheduled to two meetings simultaneously - 
switching topics and sessions around is going to confuse both people and 
the scheduler algorithm.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: Plumbers: Please split audio topics into separate sessions

[Mark Brown]

On Mon, Aug 06, 2012 at 10:11:44PM +0200, David Henningsson wrote:
> On 08/06/2012 09:29 PM, Takashi Iwai wrote:

>> Well, as already announced, each topic was planned to be about 20
>> minutes, so I don't think we need to extend session time.

> Judging from our last experience, where we had a two-hour session on  
> Sunday and then had to reschedule on Wednesday for two more hours, and  
> yet had to cancel the topic I was about to introduce, because everybody  
> was tired (and waiting for lunch), I certainly beg to differ!

Hrm?  Was this Plumbers or the BoF in Prague last year?

>> Of course, it's possible to ask more slots, if you are sure that one
>> topic would need really 40 minutes discussions.

> It's the discussions that take time.

On the other hand if we don't have much concrete to discuss then it can
end up being too long.

I guess this is one of the concerns I have with having lots of sessions
- it means we've split topics up and have less play to manage time
overall, it means we either cover less or take more time.  The
flexibility for attendees is good, though - have to see how the
tradeoffs work.

> Also all of the 45 minutes is not effective discussion/presentation  
> time: Assume that we first wait 5 minutes for all people to appear, then  
> we have 5 minutes presentation and 15 - 20 minutes discussion for the  
> first topic, then 5 minutes are spent fiddling with the projector to  
> show the slides for the second topic...and suddenly there is just a few  
> minutes left for discussion of the second topic.

This is a bit of a concern, yes.  

> Also; we fly across half the world to get there, to spend just a few  
> minutes talking? Better have some margins. Maybe some session will end  
> early, but will it hurt? No. If we miss a topic, or have to cut it short  
> without a conclusion, will it hurt? Yes.

Perhaps the best thing is to have an additional session for overrun
rather than plan on everything being 45 minutes long?

Re: Plumbers: Please split audio topics into separate sessions

[Takashi Iwai]

At Mon, 6 Aug 2012 23:24:17 +0100,
Mark Brown wrote:
> 
> On Mon, Aug 06, 2012 at 10:11:44PM +0200, David Henningsson wrote:
> > On 08/06/2012 09:29 PM, Takashi Iwai wrote:
> 
> >> Well, as already announced, each topic was planned to be about 20
> >> minutes, so I don't think we need to extend session time.
> 
> > Judging from our last experience, where we had a two-hour session on  
> > Sunday and then had to reschedule on Wednesday for two more hours, and  
> > yet had to cancel the topic I was about to introduce, because everybody  
> > was tired (and waiting for lunch), I certainly beg to differ!
> 
> Hrm?  Was this Plumbers or the BoF in Prague last year?
> 
> >> Of course, it's possible to ask more slots, if you are sure that one
> >> topic would need really 40 minutes discussions.
> 
> > It's the discussions that take time.
> 
> On the other hand if we don't have much concrete to discuss then it can
> end up being too long.
> 
> I guess this is one of the concerns I have with having lots of sessions
> - it means we've split topics up and have less play to manage time
> overall, it means we either cover less or take more time.  The
> flexibility for attendees is good, though - have to see how the
> tradeoffs work.

My initial idea is to kick off discussions in the sessions, then
continue at BoF or whatever if not finished in time.  This is often
more fruitful than too lengthy discussions.  You can cool down and
reconsider the idea.

> > Also all of the 45 minutes is not effective discussion/presentation  
> > time: Assume that we first wait 5 minutes for all people to appear, then  
> > we have 5 minutes presentation and 15 - 20 minutes discussion for the  
> > first topic, then 5 minutes are spent fiddling with the projector to  
> > show the slides for the second topic...and suddenly there is just a few  
> > minutes left for discussion of the second topic.
> 
> This is a bit of a concern, yes.  

Yeah, but we should apply a strict rule in such a case.
The preparation must be done before the session.  If not, the topic
should be started without the video.  Also, the topic is cut strictly
in time.

> > Also; we fly across half the world to get there, to spend just a few  
> > minutes talking? Better have some margins. Maybe some session will end  
> > early, but will it hurt? No. If we miss a topic, or have to cut it short  
> > without a conclusion, will it hurt? Yes.
> 
> Perhaps the best thing is to have an additional session for overrun
> rather than plan on everything being 45 minutes long?

As mentioned, we have already one additional slot, currently planned
for my channel-mapping API topic.  I can shorten the topic and the
almost whole slot can be used for other discussions.

And, if needed, we can ask for a slot/room for BoF beforehand in
addition.


Takashi

Re: Plumbers: Please split audio topics into separate sessions

[Vinod Koul]

On Tue, 2012-08-07 at 07:58 +0200, Takashi Iwai wrote:
> At Mon, 6 Aug 2012 23:24:17 +0100,
> Mark Brown wrote:
> > 
> > On Mon, Aug 06, 2012 at 10:11:44PM +0200, David Henningsson wrote:
> > > On 08/06/2012 09:29 PM, Takashi Iwai wrote:
> > 
> > >> Well, as already announced, each topic was planned to be about 20
> > >> minutes, so I don't think we need to extend session time.
> > 
> > > Judging from our last experience, where we had a two-hour session on  
> > > Sunday and then had to reschedule on Wednesday for two more hours, and  
> > > yet had to cancel the topic I was about to introduce, because everybody  
> > > was tired (and waiting for lunch), I certainly beg to differ!
> > 
> > Hrm?  Was this Plumbers or the BoF in Prague last year?
> > 
> > >> Of course, it's possible to ask more slots, if you are sure that one
> > >> topic would need really 40 minutes discussions.
> > 
> > > It's the discussions that take time.
> > 
> > On the other hand if we don't have much concrete to discuss then it can
> > end up being too long.
Given the people participating and topics we have I think we should have
a really good discussion and I feel time maybe less.
> > 
> > I guess this is one of the concerns I have with having lots of sessions
> > - it means we've split topics up and have less play to manage time
> > overall, it means we either cover less or take more time.  The
> > flexibility for attendees is good, though - have to see how the
> > tradeoffs work.
> 
> My initial idea is to kick off discussions in the sessions, then
> continue at BoF or whatever if not finished in time.  This is often
> more fruitful than too lengthy discussions.  You can cool down and
> reconsider the idea.
> 
> > > Also all of the 45 minutes is not effective discussion/presentation  
> > > time: Assume that we first wait 5 minutes for all people to appear, then  
> > > we have 5 minutes presentation and 15 - 20 minutes discussion for the  
> > > first topic, then 5 minutes are spent fiddling with the projector to  
> > > show the slides for the second topic...and suddenly there is just a few  
> > > minutes left for discussion of the second topic.
> > 
> > This is a bit of a concern, yes.  
> 
> Yeah, but we should apply a strict rule in such a case.
> The preparation must be done before the session.  If not, the topic
> should be started without the video.  Also, the topic is cut strictly
> in time.
> 
> > > Also; we fly across half the world to get there, to spend just a few  
> > > minutes talking? Better have some margins. Maybe some session will end  
> > > early, but will it hurt? No. If we miss a topic, or have to cut it short  
> > > without a conclusion, will it hurt? Yes.
+1

> > 
> > Perhaps the best thing is to have an additional session for overrun
> > rather than plan on everything being 45 minutes long?
> 
> As mentioned, we have already one additional slot, currently planned
> for my channel-mapping API topic.  I can shorten the topic and the
> almost whole slot can be used for other discussions.
Please keep this one, its needed :)
> 
> And, if needed, we can ask for a slot/room for BoF beforehand in
> addition.
I think one more slot would be good idea for any more prolonged
discussion and "hot-topics" :)

-- 
~Vinod

Re: Plumbers: Please split audio topics into separate sessions

[David Henningsson]

(Answer to both of you)

On 08/07/2012 07:58 AM, Takashi Iwai wrote:
> At Mon, 6 Aug 2012 23:24:17 +0100,
> Mark Brown wrote:
>>
>> On Mon, Aug 06, 2012 at 10:11:44PM +0200, David Henningsson wrote:
>>> On 08/06/2012 09:29 PM, Takashi Iwai wrote:
>>
>>>> Well, as already announced, each topic was planned to be about 20
>>>> minutes, so I don't think we need to extend session time.
>>
>>> Judging from our last experience, where we had a two-hour session on
>>> Sunday and then had to reschedule on Wednesday for two more hours, and
>>> yet had to cancel the topic I was about to introduce, because everybody
>>> was tired (and waiting for lunch), I certainly beg to differ!
>>
>> Hrm?  Was this Plumbers or the BoF in Prague last year?

The BoF in Prague.

>> On the other hand if we don't have much concrete to discuss then it can
>> end up being too long.
>>
>> I guess this is one of the concerns I have with having lots of sessions
>> - it means we've split topics up and have less play to manage time
>> overall, it means we either cover less or take more time.  The
>> flexibility for attendees is good, though - have to see how the
>> tradeoffs work.

I'm not sure I follow, but if you're worried that you will miss sessions 
of other tracks, mark yourself as "Participation essential" do the 
blueprints, and the scheduler will try to not schedule them in parallel.

> My initial idea is to kick off discussions in the sessions, then
> continue at BoF or whatever if not finished in time.  This is often
> more fruitful than too lengthy discussions.  You can cool down and
> reconsider the idea.

If we're going to have spill-over sessions, I think they will need to be 
more formalised than "BoF or whatever". Otherwise people might not show 
up (due to having to attend other sessions, for example).

>>> Also all of the 45 minutes is not effective discussion/presentation
>>> time: Assume that we first wait 5 minutes for all people to appear, then
>>> we have 5 minutes presentation and 15 - 20 minutes discussion for the
>>> first topic, then 5 minutes are spent fiddling with the projector to
>>> show the slides for the second topic...and suddenly there is just a few
>>> minutes left for discussion of the second topic.
>>
>> This is a bit of a concern, yes.
>
> Yeah, but we should apply a strict rule in such a case.
> The preparation must be done before the session.  If not, the topic
> should be started without the video.

With only 5 minutes between sessions, there is no time to do 
preparations (i e checking the projector and stuff).

 > Also, the topic is cut strictly in time.

Maybe it will work if we at the time of overrun stop discussion, and 
instead only reply with SND_PCM_STATE_XRUN ;-)

>>> Also; we fly across half the world to get there, to spend just a few
>>> minutes talking? Better have some margins. Maybe some session will end
>>> early, but will it hurt? No. If we miss a topic, or have to cut it short
>>> without a conclusion, will it hurt? Yes.
>>
>> Perhaps the best thing is to have an additional session for overrun
>> rather than plan on everything being 45 minutes long?
>
> As mentioned, we have already one additional slot, currently planned
> for my channel-mapping API topic.  I can shorten the topic and the
> almost whole slot can be used for other discussions.

Since I don't seem to get understanding for the need to have 45 min 
sessions per topic, which I still believe would be the best option, can 
we split the channel-mapping API topic with a new topic - "simplifying 
volume set/get on startup and shutdown"?

> And, if needed, we can ask for a slot/room for BoF beforehand in
> addition.

Can we ensure that the required participants make it to that slot/room then?

Also we need to make sure that the spill-over slot(s) happens *after* 
the other sessions. Right now the session you say can be used for 
spill-over sessions (channel-mapping API topic), is scheduled before the 
actual sessions that can spill over.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: Plumbers: Please split audio topics into separate sessions

[Takashi Iwai]

At Tue, 07 Aug 2012 08:41:51 +0200,
David Henningsson wrote:
> 
> (Answer to both of you)
> 
> On 08/07/2012 07:58 AM, Takashi Iwai wrote:
> > At Mon, 6 Aug 2012 23:24:17 +0100,
> > Mark Brown wrote:
> >>
> >> On Mon, Aug 06, 2012 at 10:11:44PM +0200, David Henningsson wrote:
> >>> On 08/06/2012 09:29 PM, Takashi Iwai wrote:
> >>
> >>>> Well, as already announced, each topic was planned to be about 20
> >>>> minutes, so I don't think we need to extend session time.
> >>
> >>> Judging from our last experience, where we had a two-hour session on
> >>> Sunday and then had to reschedule on Wednesday for two more hours, and
> >>> yet had to cancel the topic I was about to introduce, because everybody
> >>> was tired (and waiting for lunch), I certainly beg to differ!
> >>
> >> Hrm?  Was this Plumbers or the BoF in Prague last year?
> 
> The BoF in Prague.

That was the problem of having too long time slot.  Discussions tend
to be either too deep or too boring when continued for long time.

> >> On the other hand if we don't have much concrete to discuss then it can
> >> end up being too long.
> >>
> >> I guess this is one of the concerns I have with having lots of sessions
> >> - it means we've split topics up and have less play to manage time
> >> overall, it means we either cover less or take more time.  The
> >> flexibility for attendees is good, though - have to see how the
> >> tradeoffs work.
> 
> I'm not sure I follow, but if you're worried that you will miss sessions 
> of other tracks, mark yourself as "Participation essential" do the 
> blueprints, and the scheduler will try to not schedule them in parallel.
> 
> > My initial idea is to kick off discussions in the sessions, then
> > continue at BoF or whatever if not finished in time.  This is often
> > more fruitful than too lengthy discussions.  You can cool down and
> > reconsider the idea.
> 
> If we're going to have spill-over sessions, I think they will need to be 
> more formalised than "BoF or whatever". Otherwise people might not show 
> up (due to having to attend other sessions, for example).

Yes, having a closing discussion session sounds good.

> >>> Also all of the 45 minutes is not effective discussion/presentation
> >>> time: Assume that we first wait 5 minutes for all people to appear, then
> >>> we have 5 minutes presentation and 15 - 20 minutes discussion for the
> >>> first topic, then 5 minutes are spent fiddling with the projector to
> >>> show the slides for the second topic...and suddenly there is just a few
> >>> minutes left for discussion of the second topic.
> >>
> >> This is a bit of a concern, yes.
> >
> > Yeah, but we should apply a strict rule in such a case.
> > The preparation must be done before the session.  If not, the topic
> > should be started without the video.
> 
> With only 5 minutes between sessions, there is no time to do 
> preparations (i e checking the projector and stuff).

You can check it in the morning or the lunch pause.

Or maybe at best give slides in PDF format beforehand so that we
don't have to switch the machine.  This worked well in many
conferences.

>  > Also, the topic is cut strictly in time.
> 
> Maybe it will work if we at the time of overrun stop discussion, and 
> instead only reply with SND_PCM_STATE_XRUN ;-)

Yes, it should be preemptive RT :)

> >>> Also; we fly across half the world to get there, to spend just a few
> >>> minutes talking? Better have some margins. Maybe some session will end
> >>> early, but will it hurt? No. If we miss a topic, or have to cut it short
> >>> without a conclusion, will it hurt? Yes.
> >>
> >> Perhaps the best thing is to have an additional session for overrun
> >> rather than plan on everything being 45 minutes long?
> >
> > As mentioned, we have already one additional slot, currently planned
> > for my channel-mapping API topic.  I can shorten the topic and the
> > almost whole slot can be used for other discussions.
> 
> Since I don't seem to get understanding for the need to have 45 min 
> sessions per topic, which I still believe would be the best option, can 
> we split the channel-mapping API topic with a new topic - "simplifying 
> volume set/get on startup and shutdown"?

Sorry, I don't understand what you mean here.  The channel-mapping API
has nothing to do with volume get/set things...  So you are proposing
a completely new topic now?

The channel-API topic slot was considered to be an optional one from
the beginning.  I got the slot lately in case anyone would like to
bring up new topics, e.g. use it for lightening talks.  So, if you
have a new topic proposal, it's fine.  Let's assign there.


> > And, if needed, we can ask for a slot/room for BoF beforehand in
> > addition.
> 
> Can we ensure that the required participants make it to that slot/room then?

Yeah I meant as an official (5th) slot, so people can check it
rightly.

> Also we need to make sure that the spill-over slot(s) happens *after* 
> the other sessions. Right now the session you say can be used for 
> spill-over sessions (channel-mapping API topic), is scheduled before the 
> actual sessions that can spill over.

It was already asked yesterday.  Rearranging the topics in the audio
microconf is no big issue.

But allocating a new room is another question.  So, if more time slots
(i.e. rooms) are required, we must ask ASAP.


Takashi

Re: Plumbers: Please split audio topics into separate sessions

[David Henningsson]

On 08/07/2012 09:11 AM, Takashi Iwai wrote:

>>>>> Judging from our last experience, where we had a two-hour session on
>>>>> Sunday and then had to reschedule on Wednesday for two more hours, and
>>>>> yet had to cancel the topic I was about to introduce, because everybody
>>>>> was tired (and waiting for lunch), I certainly beg to differ!
>>>>
>>>> Hrm?  Was this Plumbers or the BoF in Prague last year?
>>
>> The BoF in Prague.
>
> That was the problem of having too long time slot.  Discussions tend
> to be either too deep or too boring when continued for long time.

We'll have to agree to disagree on that.

>>>>> Also; we fly across half the world to get there, to spend just a few
>>>>> minutes talking? Better have some margins. Maybe some session will end
>>>>> early, but will it hurt? No. If we miss a topic, or have to cut it short
>>>>> without a conclusion, will it hurt? Yes.

Btw, take "HD Audio cooking recipe" as an example. We will discuss:

  * debugging practices for typical problems
  * open problems
  * jack retasking
  * HDMI stream assignment
  * missing speaker/mic streams
  * better interaction / organization with user-space applications like 
PulseAudio

For 15-20 minutes in total, that gives approximately 3 minutes per 
sub-topic. (!)

>> Since I don't seem to get understanding for the need to have 45 min
>> sessions per topic, which I still believe would be the best option, can
>> we split the channel-mapping API topic with a new topic - "simplifying
>> volume set/get on startup and shutdown"?
>
> Sorry, I don't understand what you mean here.  The channel-mapping API
> has nothing to do with volume get/set things...  So you are proposing
> a completely new topic now?
>
> The channel-API topic slot was considered to be an optional one from
> the beginning.  I got the slot lately in case anyone would like to
> bring up new topics, e.g. use it for lightening talks.  So, if you
> have a new topic proposal, it's fine.  Let's assign there.

New topic suggestion:

Simplifying volume setting on startup/shutdown
====================
Currently, on a normal desktop session, volume is set four times on 
startup - initally by the kernel, then by alsactl, then by PulseAudio in 
the DM session, then by PulseAudio in the logged in session.

When shutting down, both PulseAudio and alsactl saves volumes to restore 
them later. And then we also have suspend and hibernate to consider, and 
that cards can be plugged in at any time.

First, isn't this quite complex for something as simple as setting 
volumes? Second, can we facilitate new features, such as 1) having a 
"set this volume as default, for all users, on startup" button in the 
volume control, or 2) "allow the DM user to introspect different users' 
volumes"?
===================

This is mostly a problem statement. I don't have a good proposal for how 
to simplify it.

>>> And, if needed, we can ask for a slot/room for BoF beforehand in
>>> addition.
>>
>> Can we ensure that the required participants make it to that slot/room then?
>
> Yeah I meant as an official (5th) slot, so people can check it
> rightly.

Ok, if we can't have 45 minutes per topic, a 5th slot is better than 
nothing.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: Plumbers: Please split audio topics into separate sessions

[Takashi Iwai]

At Tue, 07 Aug 2012 10:08:54 +0200,
David Henningsson wrote:
> 
> On 08/07/2012 09:11 AM, Takashi Iwai wrote:
> 
> >>>>> Judging from our last experience, where we had a two-hour session on
> >>>>> Sunday and then had to reschedule on Wednesday for two more hours, and
> >>>>> yet had to cancel the topic I was about to introduce, because everybody
> >>>>> was tired (and waiting for lunch), I certainly beg to differ!
> >>>>
> >>>> Hrm?  Was this Plumbers or the BoF in Prague last year?
> >>
> >> The BoF in Prague.
> >
> > That was the problem of having too long time slot.  Discussions tend
> > to be either too deep or too boring when continued for long time.
> 
> We'll have to agree to disagree on that.

Heh.  Actually it's like a question of CPU scheduler...

> >>>>> Also; we fly across half the world to get there, to spend just a few
> >>>>> minutes talking? Better have some margins. Maybe some session will end
> >>>>> early, but will it hurt? No. If we miss a topic, or have to cut it short
> >>>>> without a conclusion, will it hurt? Yes.
> 
> Btw, take "HD Audio cooking recipe" as an example. We will discuss:
> 
>   * debugging practices for typical problems
>   * open problems
>   * jack retasking
>   * HDMI stream assignment
>   * missing speaker/mic streams
>   * better interaction / organization with user-space applications like 
> PulseAudio
> 
> For 15-20 minutes in total, that gives approximately 3 minutes per 
> sub-topic. (!)

So this is a good chance to reconsider what to be discussed.

The first one, for example, can be well merged to another topic
"automatic testing using hda-emu". Jack retasking, HDMI streams and
missing speaker/mic streams, are things to be discussed from two
perspectives: the driver side and the user-space (i.e. PA) side.
And for Plumbers, these should be the topics from the latter POV.

Also, the next, the automatic testing topic can be shorter than the
former, so we can think of this whole 45 minutes slot as hd-audio slot
in practice.

> >> Since I don't seem to get understanding for the need to have 45 min
> >> sessions per topic, which I still believe would be the best option, can
> >> we split the channel-mapping API topic with a new topic - "simplifying
> >> volume set/get on startup and shutdown"?
> >
> > Sorry, I don't understand what you mean here.  The channel-mapping API
> > has nothing to do with volume get/set things...  So you are proposing
> > a completely new topic now?
> >
> > The channel-API topic slot was considered to be an optional one from
> > the beginning.  I got the slot lately in case anyone would like to
> > bring up new topics, e.g. use it for lightening talks.  So, if you
> > have a new topic proposal, it's fine.  Let's assign there.
> 
> New topic suggestion:
> 
> Simplifying volume setting on startup/shutdown
> ====================
> Currently, on a normal desktop session, volume is set four times on 
> startup - initally by the kernel, then by alsactl, then by PulseAudio in 
> the DM session, then by PulseAudio in the logged in session.
> 
> When shutting down, both PulseAudio and alsactl saves volumes to restore 
> them later. And then we also have suspend and hibernate to consider, and 
> that cards can be plugged in at any time.
> 
> First, isn't this quite complex for something as simple as setting 
> volumes? Second, can we facilitate new features, such as 1) having a 
> "set this volume as default, for all users, on startup" button in the 
> volume control, or 2) "allow the DM user to introspect different users' 
> volumes"?
> ===================
> 
> This is mostly a problem statement. I don't have a good proposal for how 
> to simplify it.

OK, could you create a blueprint with that content?
Then I'll inform plumbers committee about the addition as another
(5th) slot at first.  Then we can rearrange topics in 5 slots.

> >>> And, if needed, we can ask for a slot/room for BoF beforehand in
> >>> addition.
> >>
> >> Can we ensure that the required participants make it to that slot/room then?
> >
> > Yeah I meant as an official (5th) slot, so people can check it
> > rightly.
> 
> Ok, if we can't have 45 minutes per topic, a 5th slot is better than 
> nothing.

Well, I'm not totally against 45 minutes per topic.  If the topic is
really worth for 45 minutes, then we can assign to a full slot, yes.
But one should consider again whether the topics are really mandatory
to be discussed at Plumbers.  For example, if a topic is way too
deeply involved with coding, it isn't.  Better discussed on ML.


Takashi

Re: Plumbers: Please split audio topics into separate sessions

[David Henningsson]

On 08/07/2012 10:35 AM, Takashi Iwai wrote:
>> New topic suggestion:
>>
>> Simplifying volume setting on startup/shutdown
>> ====================
>> Currently, on a normal desktop session, volume is set four times on
>> startup - initally by the kernel, then by alsactl, then by PulseAudio in
>> the DM session, then by PulseAudio in the logged in session.
>>
>> When shutting down, both PulseAudio and alsactl saves volumes to restore
>> them later. And then we also have suspend and hibernate to consider, and
>> that cards can be plugged in at any time.
>>
>> First, isn't this quite complex for something as simple as setting
>> volumes? Second, can we facilitate new features, such as 1) having a
>> "set this volume as default, for all users, on startup" button in the
>> volume control, or 2) "allow the DM user to introspect different users'
>> volumes"?
>> ===================
>>
>> This is mostly a problem statement. I don't have a good proposal for how
>> to simplify it.
>
> OK, could you create a blueprint with that content?
> Then I'll inform plumbers committee about the addition as another
> (5th) slot at first.  Then we can rearrange topics in 5 slots.

Ok, new blueprint added as 
https://blueprints.launchpad.net/lpc/+spec/lpc2012-audio-simplify-volumes


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: Plumbers: Please split audio topics into separate sessions

[Mark Brown]

On Tue, Aug 07, 2012 at 10:08:54AM +0200, David Henningsson wrote:

> When shutting down, both PulseAudio and alsactl saves volumes to
> restore them later. And then we also have suspend and hibernate to
> consider, and that cards can be plugged in at any time.

> This is mostly a problem statement. I don't have a good proposal for
> how to simplify it.

Isn't this a fairly simple Pulse/distro issue?  It seems like alsactl is
redundant for most distros now so they could just disable it by default
meaning we just have to worry about the DM/user Pulse handover.  For
that I guess if Pulse does something the distros would be happy to just
follow that?

Re: Plumbers: Please split audio topics into separate sessions

[David Henningsson]

On 08/07/2012 01:15 PM, Mark Brown wrote:
> On Tue, Aug 07, 2012 at 10:08:54AM +0200, David Henningsson wrote:
>
>> When shutting down, both PulseAudio and alsactl saves volumes to
>> restore them later. And then we also have suspend and hibernate to
>> consider, and that cards can be plugged in at any time.
>
>> This is mostly a problem statement. I don't have a good proposal for
>> how to simplify it.
>
> Isn't this a fairly simple Pulse/distro issue?

PulseAudio - no, because PulseAudio does not control *all* volumes. 
They're partially overlapping, but not completely.

Distro - well, a distro can do anything they/we want, but 
recommendations from upstream will reduce confusion and risk for distros 
being bonked by upstream with the "you're doing it wrong, stupid!" message.

> It seems like alsactl is
> redundant for most distros now so they could just disable it by default
> meaning we just have to worry about the DM/user Pulse handover.

That could be a way forward worth discussing at the session, but that's 
not the way it works now.

> For
> that I guess if Pulse does something the distros would be happy to just
> follow that?

Not all distros use PulseAudio either, but maybe that's beyond the scope 
of the actual discussion.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: Plumbers: Please split audio topics into separate sessions

[Mark Brown]

On Tue, Aug 07, 2012 at 01:26:37PM +0200, David Henningsson wrote:
> On 08/07/2012 01:15 PM, Mark Brown wrote:

> >Isn't this a fairly simple Pulse/distro issue?

> PulseAudio - no, because PulseAudio does not control *all* volumes.
> They're partially overlapping, but not completely.

Oh, that's very surprising - my understanding had been that PulseAudio
was essentially just ignoring the configuration it got on startup.  Is
there any great reason not to subsume the functionality currently done
using alsactl?

> Distro - well, a distro can do anything they/we want, but
> recommendations from upstream will reduce confusion and risk for
> distros being bonked by upstream with the "you're doing it wrong,
> stupid!" message.

What I was suggetsing was that this become our advice for the distros.

> >For
> >that I guess if Pulse does something the distros would be happy to just
> >follow that?

> Not all distros use PulseAudio either, but maybe that's beyond the
> scope of the actual discussion.

I think so, if they're replacing all the software managing the
configuration they ought to be comfortable doing their own replacement.

Re: Plumbers: Please split audio topics into separate sessions

[Takashi Iwai]

At Tue, 7 Aug 2012 14:57:36 +0100,
Mark Brown wrote:
> 
> On Tue, Aug 07, 2012 at 01:26:37PM +0200, David Henningsson wrote:
> > On 08/07/2012 01:15 PM, Mark Brown wrote:
> 
> > >Isn't this a fairly simple Pulse/distro issue?
> 
> > PulseAudio - no, because PulseAudio does not control *all* volumes.
> > They're partially overlapping, but not completely.
> 
> Oh, that's very surprising - my understanding had been that PulseAudio
> was essentially just ignoring the configuration it got on startup.  Is
> there any great reason not to subsume the functionality currently done
> using alsactl?

Well, you can't know all subtle controls exactly.  For example, what
PA should do for a control like "Never Turn Off This Capture Switch"?
It can be included in a card-specific database PA holds, but if it's
not there (suppose it's a shiny new driver), the safest way is to
leave it as is.


Takashi

Re: Plumbers: Please split audio topics into separate sessions

[Mark Brown]

On Tue, Aug 07, 2012 at 04:04:04PM +0200, Takashi Iwai wrote:
> Mark Brown wrote:

> > Oh, that's very surprising - my understanding had been that PulseAudio
> > was essentially just ignoring the configuration it got on startup.  Is
> > there any great reason not to subsume the functionality currently done
> > using alsactl?

> Well, you can't know all subtle controls exactly.  For example, what
> PA should do for a control like "Never Turn Off This Capture Switch"?
> It can be included in a card-specific database PA holds, but if it's
> not there (suppose it's a shiny new driver), the safest way is to
> leave it as is.

Yes, I was assuming that this was what it was doing - I just thought
that there was functionality for doing the stuff alsactl is being used
for in PulseAudio.

Re: Plumbers: Please split audio topics into separate sessions

[Mark Brown]

On Mon, Aug 06, 2012 at 09:09:24PM +0200, David Henningsson wrote:

> Audio uConf: HD-audio cooking && QA/Testing
> Audio uConf: Expose Routing && DSPs in ASoC
> Audio uConf: Time Alignment && PA on Android

> Please split these three sessions into six. It is better to have a  
> little more time than necessary (even if I believe we easily fill 45  
> minutes per topic), than having to skip a topic just because the other  
> topic took more time than expected.

The two ASoC topics certainly don't need to be split, they're roughly
the same area.  I'd be really surprised if the last two were terribly
time consuming individually.

Re: Plumbers: Please split audio topics into separate sessions

[David Henningsson]

On 08/06/2012 09:38 PM, Mark Brown wrote:
> On Mon, Aug 06, 2012 at 09:09:24PM +0200, David Henningsson wrote:
>
>> Audio uConf: HD-audio cooking && QA/Testing
>> Audio uConf: Expose Routing && DSPs in ASoC
>> Audio uConf: Time Alignment && PA on Android
>
>> Please split these three sessions into six. It is better to have a
>> little more time than necessary (even if I believe we easily fill 45
>> minutes per topic), than having to skip a topic just because the other
>> topic took more time than expected.
>
> The two ASoC topics certainly don't need to be split, they're roughly
> the same area.  I'd be really surprised if the last two were terribly
> time consuming individually.

What other topic than "DSPs on ASoC" are you referring to? I thought 
"Expose routing" was not ASoC specific. At least it does not look that 
way from the presentation text.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: Plumbers: Please split audio topics into separate sessions

[Mark Brown]

On Mon, Aug 06, 2012 at 10:14:56PM +0200, David Henningsson wrote:
> On 08/06/2012 09:38 PM, Mark Brown wrote:

>> The two ASoC topics certainly don't need to be split, they're roughly
>> the same area.  I'd be really surprised if the last two were terribly
>> time consuming individually.

> What other topic than "DSPs on ASoC" are you referring to? I thought  
> "Expose routing" was not ASoC specific. At least it does not look that  
> way from the presentation text.

Those two - the routing is mostly an ASoC thing, HDA could use it but
none of the desktop guys ever seemed really interested and it's more
likely that any active work on that is going to come from people with
DSPs.  I guess ASoC isn't the right term, though.

Re: Plumbers: Please split audio topics into separate sessions

[Vinod Koul]

On Mon, 2012-08-06 at 20:38 +0100, Mark Brown wrote:
> On Mon, Aug 06, 2012 at 09:09:24PM +0200, David Henningsson wrote:
> 
> > Audio uConf: HD-audio cooking && QA/Testing
> > Audio uConf: Expose Routing && DSPs in ASoC
> > Audio uConf: Time Alignment && PA on Android
> 
> > Please split these three sessions into six. It is better to have a  
> > little more time than necessary (even if I believe we easily fill 45  
> > minutes per topic), than having to skip a topic just because the other  
> > topic took more time than expected.
> 
> The two ASoC topics certainly don't need to be split, they're roughly
> the same area.  I'd be really surprised if the last two were terribly
> time consuming individually.
Well it was three proposals, Liam's, ours and your routing one. So maybe
little tight to complete in 20minutes.
Also it would be good to have a summary from you/Liam on advances in
ASoC and future plans, the core has changed a lot since last Plumbers :)

-- 
~Vinod

Re: Plumbers: Please split audio topics into separate sessions

[Takashi Iwai]

At Tue, 07 Aug 2012 12:12:29 +0530,
Vinod Koul wrote:
> 
> On Mon, 2012-08-06 at 20:38 +0100, Mark Brown wrote:
> > On Mon, Aug 06, 2012 at 09:09:24PM +0200, David Henningsson wrote:
> > 
> > > Audio uConf: HD-audio cooking && QA/Testing
> > > Audio uConf: Expose Routing && DSPs in ASoC
> > > Audio uConf: Time Alignment && PA on Android
> > 
> > > Please split these three sessions into six. It is better to have a  
> > > little more time than necessary (even if I believe we easily fill 45  
> > > minutes per topic), than having to skip a topic just because the other  
> > > topic took more time than expected.
> > 
> > The two ASoC topics certainly don't need to be split, they're roughly
> > the same area.  I'd be really surprised if the last two were terribly
> > time consuming individually.
> Well it was three proposals, Liam's, ours and your routing one. So maybe
> little tight to complete in 20minutes.

One slot is 45 minutes.


Takashi

Re: Plumbers: Please split audio topics into separate sessions

[Mark Brown]

On Tue, Aug 07, 2012 at 12:12:29PM +0530, Vinod Koul wrote:

> Well it was three proposals, Liam's, ours and your routing one. So maybe
> little tight to complete in 20minutes.

They're all very similar, the DSP one in particular should be very
quick.

> Also it would be good to have a summary from you/Liam on advances in
> ASoC and future plans, the core has changed a lot since last Plumbers :)

There's nothing really to say there, nothing's changed from the
previous lists of things except for some stuff got done.