[pulseaudio-discuss] Order-based or priority-based default device?

[David Henningsson]

On 09/07/2011 08:32 PM, Arun Raghavan wrote:
> On Wed, 2011-09-07 at 15:37 +0200, David Henningsson wrote:
> [...]
>> I've tried to talk to a few people, and from what I can tell, there is
>> no point in time when the system can be considered to be fully "up and
>> running". This means e g, if a new bluetooth device shows up say 30
>> seconds after PulseAudio starts, we don't know if this was because
>> someone actually connected the bluetooth headset at that point, or if it
>> was connected from start but took 30 seconds to respond and negotiate
>> with the bluez stack. Same goes for USB, and in theory other devices as
>> well, but I've never seen it happen in practice to anything internal/PCI.
>>
>> Also, this applies not only at boot, but also at resume from suspend or
>> hibernate.
>>
>> Given that lack of information from the kernel/hardware, I can only
>> assume that order-based handling is bound to fail. And so is
>> module-switch-on-connect, that implements this. (And so is Ubuntu's
>> suspend/resume script, btw.)
>>
>> This leaves us rule/priority-based policy d ecisions, which I believe is
>> what Colin thinks as well. Comments?
>
> IMO, this approach to device plugging is a bit of a cop-out. Maybe a
> device appearing 10 seconds after boot/resume is not hot-plugged, but a
> device that appears>2 minutes almost certainly is. So I think with
> heuristics, we can deal with this. For example, we call the system
> booted when there are no new events for X seconds (the value of X can be
> the subject of much bikeshedding), we call the system booted/resumed.

What counts as "an event" in this context?

> I'm not involved in the bits of the stack that do this, so feel free to
> point out if I'm missing something.

I think it will be difficult to find a value of X that is good enough, 
in order to avoid people to file bugs against something working 
differently on a fast vs slow computer.

An interesting case is when user plays back sound (through e g a USB 
headset) and while doing that, he tells computer to suspend. When 
PulseAudio returns from suspend, the device is gone according to udev. 
For how long do we wait until giving up waiting for device to come back, 
and let module-rescue-streams move it to an available device?

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