[alsa-devel] Plumbers: Please split audio topics into separate sessions
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.
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
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.
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?
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
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" :)
(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.
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
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.
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
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
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?
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.
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.
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
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.
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.
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.
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.
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 :)
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
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.
participants (4)
-
David Henningsson -
Mark Brown -
Takashi Iwai -
Vinod Koul