Ah, yes, I've read this propsal. Sounds great, and yes, it's pretty clear we were arguing for the same thing, each misunderstanding what the other was suggesting :) On Tue, Jun 15, 2010 at 11:39, Colin Guthrie <gmane at colin.guthr.ie> wrote: > 'Twas brillig, and Jeremy Nickurak at 15/06/10 17:46 did gyre and gimble: >> On Tue, Jun 15, 2010 at 10:05, Colin Guthrie <gmane at colin.guthr.ie> wrote: >>> Added to this, there are numerous examples of when I really don't want, >>> nor would expect this to happen. e.g. I'm playing music and I get my USB >>> headset to make a VoIP call. My music playing happily on my USB Speakers >>> and I want it stay there, but as soon as I plug in my headset it >>> transfers. I'd much rather it stayed where it was. I may want to leave >>> my USB Headset plugged in (I often do). >> >> Okay, then the headset should be configured somehow to never become >> the fallback. Maybe that's automatic based on profile information.... >> but it should probably be overridable. Let the user say what devices >> are potential fall-back devices, and probably allow an ordering for >> them. > > Yes of course that's allowed. The whole ability to order them is the > main point of my proposal. > > The only thing that's being debated here is what happens when a brand > new, never seen before device is plugged in. > >>> The general rule is if you can't do something automatically that works >>> every time, then don't do it automatically at all, but make it easy and >>> obvious to the user how to do it manually. >> >> That's a great philosophy... but it applies mostly to hard-coding >> things. We don't want the user to have to open up a control panel and >> reconfigure things every time they plug/unplug a device, right? > > Of course not.... I'm beginning to think that you're arguing something > very different to me. I'm not suggesting for a second that the user > would have to configure something every time they plug/unplug a device. > Only that they *will* need to configure things one. We will not do > anything too clever automatically, i.e. without the user's direct > intervension unless we know we'll get it right in the vast, vast > majority of cases. I think the VoIP streams on Headsets is the likely > case for when we can get things right 99% of the time automatically. > That's not to say the user cannot make a configuration override that > will subsequently be used in preference to our automatic choices however. > >> Consider the case of docking stations, where any time the user sits >> down at their desk, they want the sound redirected to the desktop. >> (Although there's a case here to be careful about... we don't want to >> take the output to speakers if they're currently blasting high-volume >> heavy metal on headphones....) > > > OK, this confirms that we're not arguing the same thing. > > If you read my proposal, (the first link I posted very near the > beginning of this thread) you'll see that this setup will be easily > supported. > > The only think I've been talking about (and due to the concepts I'd > written in my proposal, I presumed you were talking about too) is what > happens the very *first* time a device is plugged in. > > Col. > > > -- > > Colin Guthrie > gmane(at)colin.guthr.ie > http://colin.guthr.ie/ > > Day Job: > ?Tribalogic Limited [http://www.tribalogic.net/] > Open Source: > ?Mandriva Linux Contributor [http://www.mandriva.com/] > ?PulseAudio Hacker [http://www.pulseaudio.org/] > ?Trac Hacker [http://trac.edgewall.org/] > > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at mail.0pointer.de > https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss > -- Jeremy Nickurak -= Email/XMPP: jeremy at nickurak.ca =-
