[pulseaudio-discuss] PulseAudio Mini-conference: Preliminary schedule

[David Henningsson]

Let me know if anything looks bad (or good!) here; topics needing more 
time (or less time) etc. I've mostly just laid up the topic suggestions 
in random order.

Also; if you're not attending the full day and depending on something to 
start at a specific time, let us know, otherwise we reserve the right to 
e g start with a topic early if the previous topic finished early.

Being a topic leader doesn't mean you have to bring slides. It's more 
about you saying a few sentences in the beginning, knowing what you want 
the outcome of the session to be, and trying to steer up the 
conversation if we would get side tracked.

Feedback welcome.

=============

09.30 Conference start

Reserved time to organize chairs, make sure we have equipment etc

09.45 PulseAudio - vision and mission

What do we want PulseAudio to be? What are we working for? How important 
is it for us to be the standard sound server in desktop/laptop as well 
as the embedded distributions? Other important use cases for PulseAudio? 
Are some distributions more important than others? Can we unify our 
visions for where we see PulseAudio in a few years time?

Topic leader: David Henningsson

10.30 Is there any way we can increase the patch review capacity?

The pile of unreviewed patches keeps growing. I don't have much ideas
for improving this beyond "just work harder", but maybe someone else
does...

Topic leader: Tanu Kaskinen

11.00 Coffee break

11.15 Routing priority list infrastructure

A year ago or even more, Colin Guthrie had some ideas on how to improve 
the routing infrastructure in PulseAudio, but it is still not (fully) 
implemented. Until it's there, we're hacking around the current 
limitations with e g modules such as module-switch-on-port-available, 
have rerouting problems at suspend/resume, etc.

Also, Janos Kovacs and Jaska Uimonen has started implementing some kind 
of priority/policy infrastructure, which we will also be discussing.

Topic leaders: Janos Kovacs, Jaska Uimonen

12.15 Improving low latency behaviour

Discussion about how we can make PulseAudio perform better in low 
latency scenarios, such as VOIP or gaming. In particular, the issue of 
latency increasing over time (as occasional underruns occur) should be 
somehow resolved.

12.45 Lunch

13.45 Combining system-wide and per-user modes

I think the hardware should be accessed by a system-wide pulseaudio
instance. This would finally solve the issue that root/mpd/whatever
can't have sound while someone else is logged in. The drawbacks of the
system-wide mode can be avoided by having also per-user instances taking
care of the per-user stuff.

Topic leader: Tanu Kaskinen

14.30 Devices with dynamic capabilities (e g HDMI)

HDMI in particular can change its PCM capabilities, i e, maybe you first 
have one monitor connected that supports 5.1 LPCM, and you then unplug 
and plug in another one that only supports stereo. How do we 
update/reprobe/etc PulseAudio accordingly to support this? And how does 
it relate to the just pushed patches that can add profiles/ports 
dynamically?

Topic leader: David Henningsson

15.15 Improving surround sound behaviour

More and more laptops have built in subwoofers; how can we handle/enable 
this in the best way?
Also; can we use jack detection to determine whether a certain profile 
should be available or not?

Topic leader: Arun Raghavan, David Henningsson

16.00 Coffee break

16.15 Separate configuration for hw adaptation, core and policy

In the non-desktop world there is often a need to ship different
configuration files for different hardware, and also different UIs may
need different pulseaudio policy configuration (I think this latter
point potentially applies also to the desktop world). This can be solved
with some packaging tricks, but I would like to make things easier by
having the separation also in upstream.

Topic leader: Tanu Kaskinen

17.00 Better drain/underrun reporting behaviour

We more than once has got reports that 1) drains take seconds too long 
to complete 2) underruns are reported before all samples sent have been 
actually played back, and sometimes a audio glitch can be avoided even 
when an underrun has been reported to the client. Can we get almost 
sample accuracy on when we report back that underrun/drain has occurred?

Topic leader: David Henningsson

17.30 End of conference



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