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

[David Henningsson]

On 09/07/2011 04:27 PM, Colin Guthrie wrote:
> 'Twas brillig, and David Henningsson at 07/09/11 14:37 did gyre and gimble:
>> The idea of "start to use what you plug in" is nice. If you plug
>> something in, you likely want to use it. Or do you? Anyway, that
>> approach seems to me to have an unsolvable problem: We don't know that
>> it actually was plugged in.
>>
>> 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.)
>
> Yay, I never did like that script :p

Probably stupid to mention it here as it risks the conversation going 
off-topic, but anyway, the day PulseAudio upstream offers an alternative 
solution I don't think anybody would mind removing it.

>> This leaves us rule/priority-based policy decisions, which I believe is
>> what Colin thinks as well. Comments?
>
> Yup, but you outlined it nicely :)
>
> That said, there is likely still scope for changing where in the
> priority list new devices are injected (top or bottom being the only two
> valid choices),

Hrm. I think we have to do a little bit more clever than that. I'd like 
some kind of base priority for a device that is used given that the user 
never configures anything, based on form factor and other things. Then 
exactly how a new device would interact with a priority list that user 
has messed around with, might require some thought to get intuitive.

> although that will still be subject to the problems you
> outline above. Hopefully the general use case is more "hotplug" related
> than "first boot", so I'm not sure there will be overly many practical
> problems, but you're absolutely right to consider them.

Having things working as expected out-of-the-box should not be 
underrated. First impressions last and might save me quite a few 
unnecessary bug reports as well. So IMO we need to solve both.

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