From: David Henningsson <david.henningsson@canonical.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
Mark Brown <broonie@opensource.wolfsonmicro.com>
Subject: Re: Plumbers: Please split audio topics into separate sessions
Date: Tue, 07 Aug 2012 10:08:54 +0200 [thread overview]
Message-ID: <5020CD16.6020705@canonical.com> (raw)
In-Reply-To: <s5hhasfi3b4.wl%tiwai@suse.de>
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
next prev parent reply other threads:[~2012-08-07 7:39 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-06 19:09 Plumbers: Please split audio topics into separate sessions David Henningsson
2012-08-06 19:29 ` Takashi Iwai
2012-08-06 20:11 ` David Henningsson
2012-08-06 22:24 ` Mark Brown
2012-08-07 5:58 ` Takashi Iwai
2012-08-07 6:28 ` Vinod Koul
2012-08-07 6:41 ` David Henningsson
2012-08-07 7:11 ` Takashi Iwai
2012-08-07 8:08 ` David Henningsson [this message]
2012-08-07 8:35 ` Takashi Iwai
2012-08-07 11:19 ` David Henningsson
2012-08-07 11:15 ` Mark Brown
2012-08-07 11:26 ` David Henningsson
2012-08-07 13:57 ` Mark Brown
2012-08-07 14:04 ` Takashi Iwai
2012-08-07 14:06 ` Mark Brown
2012-08-06 19:38 ` Mark Brown
2012-08-06 20:14 ` David Henningsson
2012-08-06 21:45 ` Mark Brown
2012-08-07 6:42 ` Vinod Koul
2012-08-07 7:14 ` Takashi Iwai
2012-08-07 14:07 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5020CD16.6020705@canonical.com \
--to=david.henningsson@canonical.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.