[alsa-devel] Plumbers: Please split audio topics into separate sessions
tiwai at suse.de
Tue Aug 7 09:11:59 CEST 2012
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
> > 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
> 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.
More information about the Alsa-devel