Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
Hi, On Thu, Jul 15, 2010 at 5:35 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Colin Guthrie at 08/07/10 10:40 did gyre and gimble: 'Twas brillig, and Marco Ballesio at 08/07/10 09:37 did gyre and gimble: Hi, On Wed, Jun 16, 2010 at 10:59 AM, Colin Guthrie gm...@colin.guthr.ie wrote: Now, incorporating what you suggest, I guess I have nothing against a specific module that actually manipulates a given priority list for you. e.g. you could have a module-prefer-usb-for-music module that actually implements your desired behaviour in a purely modular fashion by automatically rearranging your music priority list for you. Personally I think most users would not want it, but for those who do they can load it. sorry for jumping in the thread so late, but having worked on something similar I think a suitable project already exists. It is the resource policy, based on ohm, the git repo is at: http://meego.gitorious.org/maemo-multimedia/ohm Through this tool it's possible to seamlessly handle whatever we can consider a resource (CPU, memory, audio sink/source) depending on the system state, which may change after particular events occur (e.g. audio jack insertion or removal). Many meta-informations like a proper wiki page are missing there though, but still it's worth a consideration imho, as the project can be considered as already quite stable (let's say it's at production level for some targets). Thanks for the info. I'm actually having a meeting next week to discuss some thing on this general topic (loosely speaking) so I'll try and find out a bit more about this before then. Hmm, interesting: http://meego.gitorious.org/maemo-multimedia/ohm/commit/3274a3dca2069865de3ace9a6cef658ee7b521d1 this project is obsolete and will be replaced with something more functional in the near future. Wonder what that more interesting project could be! Actually, the level of interest couldn't be higher than the current one from my pov :), what the improvements will focus on is the more functional part. The idea is to keep a similar level of features (among them automatic audio routing like on the N900) with a smarter design. Obviously the project needs wiki page, mailing list and many other bells and whistles, but nowadays almost everybody's on vacation, so I guess we'll have to wait at least some weeks for those to arrive. In the meanwhile, reading this interesting discussion I thought that before adding complexity to pulseaudio and reinventing the wheel (it's meant to be a constructive critic), an evaluation about routing audio from a separate entity should be made, as this approach already works on existing systems. Regards, Marco 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@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
'Twas brillig, and Marco Ballesio at 16/07/10 07:58 did gyre and gimble: Hi, On Thu, Jul 15, 2010 at 5:35 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Colin Guthrie at 08/07/10 10:40 did gyre and gimble: 'Twas brillig, and Marco Ballesio at 08/07/10 09:37 did gyre and gimble: Hi, On Wed, Jun 16, 2010 at 10:59 AM, Colin Guthrie gm...@colin.guthr.ie wrote: Now, incorporating what you suggest, I guess I have nothing against a specific module that actually manipulates a given priority list for you. e.g. you could have a module-prefer-usb-for-music module that actually implements your desired behaviour in a purely modular fashion by automatically rearranging your music priority list for you. Personally I think most users would not want it, but for those who do they can load it. sorry for jumping in the thread so late, but having worked on something similar I think a suitable project already exists. It is the resource policy, based on ohm, the git repo is at: http://meego.gitorious.org/maemo-multimedia/ohm Through this tool it's possible to seamlessly handle whatever we can consider a resource (CPU, memory, audio sink/source) depending on the system state, which may change after particular events occur (e.g. audio jack insertion or removal). Many meta-informations like a proper wiki page are missing there though, but still it's worth a consideration imho, as the project can be considered as already quite stable (let's say it's at production level for some targets). Thanks for the info. I'm actually having a meeting next week to discuss some thing on this general topic (loosely speaking) so I'll try and find out a bit more about this before then. Hmm, interesting: http://meego.gitorious.org/maemo-multimedia/ohm/commit/3274a3dca2069865de3ace9a6cef658ee7b521d1 this project is obsolete and will be replaced with something more functional in the near future. Wonder what that more interesting project could be! Actually, the level of interest couldn't be higher than the current one from my pov :), what the improvements will focus on is the more functional part. The idea is to keep a similar level of features (among them automatic audio routing like on the N900) with a smarter design. Obviously the project needs wiki page, mailing list and many other bells and whistles, but nowadays almost everybody's on vacation, so I guess we'll have to wait at least some weeks for those to arrive. In the meanwhile, reading this interesting discussion I thought that before adding complexity to pulseaudio and reinventing the wheel (it's meant to be a constructive critic), an evaluation about routing audio from a separate entity should be made, as this approach already works on existing systems. Well right now there are several projects (outside of my own) going on in this field, but there does seem to be a little bit of disparity with upstream people. One project specifically is coming from the ALSA side and will get support in PA. This project is very likely to become the defacto method of operation on embedded systems and thus I would hope that people at MeeGo would talk more openly about what they are doing so as not to reinvent the wheel. I'm not against any kind of external system to deal with client routing etc. but there is simply not the same level of hooks and controls available to an external client. There will always be initial routing by PA then a move from the client. Also, the APIs currently exposed mean that certain side effects of calling certain API calls (e.g. the move_sink_input calls) cannot be avoided. Therefore I really feel that some built in routing management is the way forward. Developing a PA module is not hard and I don't really see the benefit of deveoping several different external systems: one for MeeGo, one for Gnome, one for KDE etc. etc. I'd rather build it once and let everyone use it. 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@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
Colin Guthrie schrob: 'Twas brillig, and Jan Braun at 15/07/10 06:07 did gyre and gimble: 1. Shouldn't PA do only obvious things automatically, and not bug the user about obvious things? The proposition PA automaticallly breaks stuff, so it needs to show the user how to unbreak it seems flawed. Depends on your definition. I'm a firm believer of doing the right thing automatically and if you can't work out what the right thing is, then don't do it at all. But when it does do something automatically, I'd quite like to be informed about it. This already happens on KDE with their Phonon system, so it's not unprecedented, but all the same it may not be liked by Gnomey folk. But hey, it will be optional. Ok, sonds reasonable. (Except for the assertion PA users = KDE xor Gnome. Grr. :) 2. Isn't PA a daemon and thus can't interact with the user? Or did you mean set a flag that pavucontrol etc. can read? But then the user still would have to run pavucontrol on their own... [...] It would be pretty trivial to load a notification module in the start-pulseaudio-x11 script and this was my intention. True, thanks. If you can't tell, I'm concerned about PA not staying out of my way. It'll be a module, so it will be optional. Yep. And being conditional on start-pulseaudio-x11 makes it stay out of my way automatically. Thanks! :D Jan -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
Well right now there are several projects (outside of my own) going on in this field, but there does seem to be a little bit of disparity with upstream people. One project specifically is coming from the ALSA side and will get support in PA. This project is very likely to become the defacto method of operation on embedded systems and thus I would hope that people at MeeGo would talk more openly about what they are doing so as not to reinvent the wheel. If you are talking about the audio scenarios developed by Liam, I don't think there's any sort of conflict. it's my understanding that the scenarios are mainly to configure the hardware routing and performance of a given audio device using specific settings (eg voice volume, etc). This thread is more about what output will be used if you have multiple audio accessories or peripherals. It's one level higher I guess. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
On Fri, Jul 16, 2010 at 11:41:33AM -0500, pl bossart wrote: Well right now there are several projects (outside of my own) going on in this field, but there does seem to be a little bit of disparity with upstream people. One project specifically is coming from the ALSA side and will get support in PA. This project is very likely to become the defacto method of operation on embedded systems and thus I would hope that people at MeeGo would talk more openly about what they are doing so as not to reinvent the wheel. If you are talking about the audio scenarios developed by Liam, I don't think there's any sort of conflict. it's my understanding that the scenarios are mainly to configure the hardware routing and performance of a given audio device using specific settings (eg voice volume, etc). This thread is more about what output will be used if you have multiple audio accessories or peripherals. It's one level higher I guess. I missed the start of this discussion so I'm missing some context here but there may actually quite a bit of overlap here - on systems like smartphones it's very common for all the audio to be a single integrated subsystem with multiple paths through it and the CPU as only one node in that system. Things like Bluetooth headsets wouldn't appear as a separate sound card, they'd appear as an output option on the existing sound card, and many audio paths will be connected directly through the hardware without entering the PulseAudio domain. Since there can be multiple paths through the system you can also end up with different streams on the CPU being routed separately - the classic example is having an MP3 playing to headphones and simultaneously ringtone/alert sounds routed to both headphones and speaker. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
'Twas brillig, and Jan Braun at 15/07/10 06:46 did gyre and gimble: Colin Guthrie schrob: e.g. when a new BT Headset is discovered, module-intended-roles would basically check to see whether the device is already in the voip priority list and if not, it would inject it at the top, rather than the bottom of the list (there could be various caveats included in this logic). That means the new BT headset gets priority over the old Headset. I wouldn't want that. In fact, my voip priority list would look like this: Old Headset use default/non-voip priority list and the new BT headset should add itself to the bottom, just before use default priority list. Not sure if that's an important scenario, but I thought I'd throw out the notion of incomplete priority lists. The current functionality would not change your headset if one was already in use, but it would use either one if turned on during a call. The automatic priority list stuff could be made to work in the same way too fairly easily. Otherwise it would do nothing and the default behaviour would ultimately be triggered and put new devices at the end of any priority lists. Obviously, in my scenario, the default behaviour would be to put new devices at the end of the default priority list only. Yeah, that would be my general opinion too. With the exception of certain special cases whereby certain devices are inserted slightly differently into certain lists. e.g. bluetooth devices go to the top of the voip priority list (although a caveat could be added to say it goes to the top, iff the current top is not a headset device. It may also be possible to configure this to not happen at all and always go to the end of the list. Although for the amount of times an average user registers new headset devices, it may not be worth making this configurable just change the config and it'll be fine for the future. 'Twas brillig, and Jason Taylor at 16/06/10 00:58 did gyre and gimble: I want to be able to tell my sister that all she has to do to use her headset is plug it in. If she has just bought that headset, that's impossible. At least not without getting MY sister in trouble because she plugged her new headset in and her speakers stopped working. There's no default for that sitation that satisfies everyone, hence the default should be the least surprising action. Which IMHO is as you were and requiring manual intervention to play music on the new device. On the other hand, after having configured PA *once* to play your sister's music on the headphones, PA certainly should remember that. (AFAICT, it currently does, and nobody wants to change that.) I generally agree with this (as I have previously stated). I do think there can be some exceptions (like headsets for voip apps), but these need to be carefully handled. 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@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
'Twas brillig, and Colin Guthrie at 08/07/10 10:40 did gyre and gimble: 'Twas brillig, and Marco Ballesio at 08/07/10 09:37 did gyre and gimble: Hi, On Wed, Jun 16, 2010 at 10:59 AM, Colin Guthrie gm...@colin.guthr.ie wrote: Now, incorporating what you suggest, I guess I have nothing against a specific module that actually manipulates a given priority list for you. e.g. you could have a module-prefer-usb-for-music module that actually implements your desired behaviour in a purely modular fashion by automatically rearranging your music priority list for you. Personally I think most users would not want it, but for those who do they can load it. sorry for jumping in the thread so late, but having worked on something similar I think a suitable project already exists. It is the resource policy, based on ohm, the git repo is at: http://meego.gitorious.org/maemo-multimedia/ohm Through this tool it's possible to seamlessly handle whatever we can consider a resource (CPU, memory, audio sink/source) depending on the system state, which may change after particular events occur (e.g. audio jack insertion or removal). Many meta-informations like a proper wiki page are missing there though, but still it's worth a consideration imho, as the project can be considered as already quite stable (let's say it's at production level for some targets). Thanks for the info. I'm actually having a meeting next week to discuss some thing on this general topic (loosely speaking) so I'll try and find out a bit more about this before then. Hmm, interesting: http://meego.gitorious.org/maemo-multimedia/ohm/commit/3274a3dca2069865de3ace9a6cef658ee7b521d1 this project is obsolete and will be replaced with something more functional in the near future. Wonder what that more interesting project could be! 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@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
Colin Guthrie schrob: 'Twas brillig, and Jeremy Nickurak at 16/06/10 16:04 did gyre and gimble: Does pulseaudio perhaps need to be throwing some visual indication to the user that streams switched devices as a result of a plug event, maybe with a very simple pointer to where to go to fix things? I've got plans for that too even a git branch, but at present it's not overly easy as PA modules cannot integrate with the glib main loop too easily... Huh? Sorry for possibly being dense, but 1. Shouldn't PA do only obvious things automatically, and not bug the user about obvious things? The proposition PA automaticallly breaks stuff, so it needs to show the user how to unbreak it seems flawed. 2. Isn't PA a daemon and thus can't interact with the user? Or did you mean set a flag that pavucontrol etc. can read? But then the user still would have to run pavucontrol on their own... If you can't tell, I'm concerned about PA not staying out of my way. regards, Jan -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
Colin Guthrie schrob: e.g. when a new BT Headset is discovered, module-intended-roles would basically check to see whether the device is already in the voip priority list and if not, it would inject it at the top, rather than the bottom of the list (there could be various caveats included in this logic). That means the new BT headset gets priority over the old Headset. I wouldn't want that. In fact, my voip priority list would look like this: Old Headset use default/non-voip priority list and the new BT headset should add itself to the bottom, just before use default priority list. Not sure if that's an important scenario, but I thought I'd throw out the notion of incomplete priority lists. Otherwise it would do nothing and the default behaviour would ultimately be triggered and put new devices at the end of any priority lists. Obviously, in my scenario, the default behaviour would be to put new devices at the end of the default priority list only. 'Twas brillig, and Jason Taylor at 16/06/10 00:58 did gyre and gimble: I want to be able to tell my sister that all she has to do to use her headset is plug it in. If she has just bought that headset, that's impossible. At least not without getting MY sister in trouble because she plugged her new headset in and her speakers stopped working. There's no default for that sitation that satisfies everyone, hence the default should be the least surprising action. Which IMHO is as you were and requiring manual intervention to play music on the new device. On the other hand, after having configured PA *once* to play your sister's music on the headphones, PA certainly should remember that. (AFAICT, it currently does, and nobody wants to change that.) regards, Jan -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
Hi, On Wed, Jun 16, 2010 at 10:59 AM, Colin Guthrie gm...@colin.guthr.ie wrote: Now, incorporating what you suggest, I guess I have nothing against a specific module that actually manipulates a given priority list for you. e.g. you could have a module-prefer-usb-for-music module that actually implements your desired behaviour in a purely modular fashion by automatically rearranging your music priority list for you. Personally I think most users would not want it, but for those who do they can load it. sorry for jumping in the thread so late, but having worked on something similar I think a suitable project already exists. It is the resource policy, based on ohm, the git repo is at: http://meego.gitorious.org/maemo-multimedia/ohm Through this tool it's possible to seamlessly handle whatever we can consider a resource (CPU, memory, audio sink/source) depending on the system state, which may change after particular events occur (e.g. audio jack insertion or removal). Many meta-informations like a proper wiki page are missing there though, but still it's worth a consideration imho, as the project can be considered as already quite stable (let's say it's at production level for some targets). Regards ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
'Twas brillig, and Marco Ballesio at 08/07/10 09:37 did gyre and gimble: Hi, On Wed, Jun 16, 2010 at 10:59 AM, Colin Guthrie gm...@colin.guthr.ie wrote: Now, incorporating what you suggest, I guess I have nothing against a specific module that actually manipulates a given priority list for you. e.g. you could have a module-prefer-usb-for-music module that actually implements your desired behaviour in a purely modular fashion by automatically rearranging your music priority list for you. Personally I think most users would not want it, but for those who do they can load it. sorry for jumping in the thread so late, but having worked on something similar I think a suitable project already exists. It is the resource policy, based on ohm, the git repo is at: http://meego.gitorious.org/maemo-multimedia/ohm Through this tool it's possible to seamlessly handle whatever we can consider a resource (CPU, memory, audio sink/source) depending on the system state, which may change after particular events occur (e.g. audio jack insertion or removal). Many meta-informations like a proper wiki page are missing there though, but still it's worth a consideration imho, as the project can be considered as already quite stable (let's say it's at production level for some targets). Thanks for the info. I'm actually having a meeting next week to discuss some thing on this general topic (loosely speaking) so I'll try and find out a bit more about this before then. 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@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
'Twas brillig, and Jason Taylor at 16/06/10 00:58 did gyre and gimble: Why does the music move to the bluetooth headset in the final example? You seem to suggest that if the priority lists for music is as follows immediately before the BT headset is attached: 1. USB Speakers 2. USB Headset 3. Internal Audio But afterwards plugging in the BT Headset, it's not clear as to whether the list is: 1. USB Speakers 2. BT Headset 3. USB Headset 4. Internal Audio or 1. USB Speakers 2. USB Headset 3. BT Headset 4. Internal Audio Both lists would achieve the result you describe as the USB Headset is not currently plugged in. I presume you mean the first example, in which case I'd infer your logic for picking the insertion point of the new device as being immediately after the highest priority available device. This would thus cause no immediate change, but certainly ensures that it messes up any careful configuration the user does. What I would like Music Streams have a user set rule of always go to USB Speakers, if the USB speakers not pugged in then follow the priority list. Priority list is the order in which I plugged devices in.. (this is local machine devices only) - Bluetooth headset - USB headset - USB speakers - Internal If a device is removed it should be removed from the priority list, so unplugging the USB headset gives - Bluetooth headset - USB speakers - Internal Plugging USB headset back in gives - USB headset - Bluetooth - USB speakers - Internal Devices which have a preferred device set should always use that device if available, else fall back to following the priority list I don't consider this magic from the point of view of the user.. its fairly simple sound moves to the device I just plugged in unless I've set up configuration to tell it not to I don't know if we are going to agree here :) I think we can agree on that last statement :p You want the user to manually select devices, I want the user to be able to override a sane (IMHO) default device selection behavior I'm not against supporting this in some capacity, but I would not want it to be the default behaviour. To summarise my original plan, what I want to see is as follows: * A core system to handle priority lists * Internal API to allow modules to manipulate where new devices enter a given priority list. (Lennart doesn't fully agree here FWIW, but that's another story). With the above approach I intended to make module-intended-roles a passive module in the sense that it will not directly manipulate the device a given stream uses, but actually dictate where in the priority list a new device is injected. e.g. when a new BT Headset is discovered, module-intended-roles would basically check to see whether the device is already in the voip priority list and if not, it would inject it at the top, rather than the bottom of the list (there could be various caveats included in this logic). Otherwise it would do nothing and the default behaviour would ultimately be triggered and put new devices at the end of any priority lists. Now, incorporating what you suggest, I guess I have nothing against a specific module that actually manipulates a given priority list for you. e.g. you could have a module-prefer-usb-for-music module that actually implements your desired behaviour in a purely modular fashion by automatically rearranging your music priority list for you. Personally I think most users would not want it, but for those who do they can load it. That way we're both happy and the decision as to whether the module is on by default can be a distro one and/or generally decided. I want to be able to tell my sister that all she has to do to use her headset is plug it in. At the moment I have to tell her to plug the headset in.. left click on the speaker icon, click settings, goto output tab, click the correct output, now restart what ever app your using You don't need to restart. Just move the stream in Playback tab and it'll work fine *and* remember it for next time. But I agree that the current way of working sucks anyway, which is why I wrote my initial proposal. 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@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
I'm not against supporting this in some capacity, but I would not want it to be the default behaviour. Here's one argument in favor of it being the default behavior... If we can't get it right automatically in general, and the user sees it happening wrong, they at least have some indication that intervention is required on their part. Does pulseaudio perhaps need to be throwing some visual indication to the user that streams switched devices as a result of a plug event, maybe with a very simple pointer to where to go to fix things? -- Jeremy Nickurak -= Email/XMPP: jer...@nickurak.ca =- ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
'Twas brillig, and Jeremy Nickurak at 16/06/10 16:04 did gyre and gimble: Does pulseaudio perhaps need to be throwing some visual indication to the user that streams switched devices as a result of a plug event, maybe with a very simple pointer to where to go to fix things? I've got plans for that too even a git branch, but at present it's not overly easy as PA modules cannot integrate with the glib main loop too easily... Lennart said he'd sort that out but that was about a year ago now :D 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@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
[I think this was meant for the list so moving it back there] 'Twas brillig, and Jason Taylor at 15/06/10 02:37 did gyre and gimble: The major use cases i have right now that suck... and are not solvable without prior knowledge of how pa works 1 - If I plug in my USB or Bluetooth headset the music does not change to headset like my analogue headset does... With your analogue headset music does not change to it, all output changes to it. I know what you're hinting at, but the two cannot be compared unless you just talk about all output. Yes by default I think pa should push all output to newly registered local devices... This is what users expect, as long as its easy to turn off advanced users wont have an issue I really don't think this is wise. There are so many cases where this doesn't work. If you are in the process of plugging something in, you *expect* to have to take some action. You're in the mind set that you'll need to take action to make the device work. I'm not saying that your suggestion is bad. I've no doubt some users would like it, but the fact remains that whenever a network device appears on my network or a bluetooth hifi in the living room appears as available, I most certainly do not want all my sound moved across to it. This is the reason why module-intended-roles is contextual. It deals with the cases where it *is* sensible to do things automatically and even then it's does them piecemeal, not wholesale. advanced meaning anyone who understands the pulseaudio volume control And novice users wont have a clue why their sound just disappeared. There is always a flip-side. With my proposal, music could be configured to move to the new USB/bluetooth headset. 2 - If I plug in a USB or Bluetooth microphone apps like *skype* can not be set to use that mic without restarting skype? Incorrect. When PA is used, Skype detects it and uses only it. It (correctly) does not offer you the configuration choice inside Skype. It is mostly up to tools like gnome-volume-control/pavucontrol etc. to configure the Skype streams, but in the case of a USB or Bluetooth headset, the PA module module-intended-roles kicks in and automatically moves voip streams to headset devices. This currently works pretty well (I don't have to do any configuration after setting up my bluetooth headset for it to just work with Skype. It's quite nice, but not very transparent. If you read the link I sent through, I believe I proposed there (maybe it was afterwards on the list - can't quite recall) that module-intended-roles becomes a passive module that simply injects brand new (never seen before) devices into the appropriate place in the priority list for the appropriate role. That way it's more transparent to the user and the net functionality remains the same. I've just retired this on ubuntu luicd with skype 2.1.0.81 (confirmed the module-intended-roles is loaded) - unplugged headset - started a call - plugged in headset - no sound - no mic input to skype.. and the current playing sound was not pushed to the headset.. although event sounds from skype seem to have done the right thing. Perhaps my headset is not detected as a headset? Ethier way it dosnt work and as you say pulse should be handling this. I can get it to go clicking the right buttons (and restarting skype), my parents or sister (who both have linux netbooks) can not... If you set up anything manually using pavucontrol, this overrides module-intended-roles, so if you've ever moved any skype stream to a new device (even if you move it back again) then m-i-r will not work for you. It's meant to deal with defaults only. pacmd list (or list-sinks for less output) will tell you if your headset is detected as a headset. There was also a bug recently in m-i-r that managed to move skype input (i.e. it's recording) to the monitor of the output which created a nice echo for the other party I've fixed this, and I believe that Ubuntu has this fix, but not 100% sure. By default I think pa should: - Move all inputs and outputs to any newly connected local device (ie usb, bluetooth whatever) that appears after pa has started (unless the per client device has been set of course) Perhaps, but I don't think everyone would agree here. I certainly would not be appropriate for my crappy bluetooth headset here. It's acceptable for phone streams, but really not for anything else. I'm not arguing it should not be configurable only default behavior No argument there. I think an option is fine, but I disagree with your default. It's also debatable whether an option is worth it considering how many new devices a user has in the lifetime of their PC. Maybe a dozen? Is moving the preference around that difficult under those circumstances? - There should be a simple UI for setting a clients default media role (if one has not been set), and this role should be remembered by pa This could be done,
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
On Tue, Jun 15, 2010 at 01:40, Colin Guthrie gm...@colin.guthr.ie wrote: I really don't think this is wise. There are so many cases where this doesn't work. If you are in the process of plugging something in, you *expect* to have to take some action. You're in the mind set that you'll need to take action to make the device work. Can't disagree strongly enough here. When you plug headphones into your laptop, the sound switches from the speakers to the headphones. No intervention. This should definitely be the same case with plugging in USB headphones. To get it right, pulseaudio's going to need some logic here, to make sure the fallback is reasonable, even in the light of plug/unplug events. -- Jeremy Nickurak -= Email/XMPP: jer...@nickurak.ca =- ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
'Twas brillig, and Jeremy Nickurak at 15/06/10 16:31 did gyre and gimble: On Tue, Jun 15, 2010 at 01:40, Colin Guthrie gm...@colin.guthr.ie wrote: I really don't think this is wise. There are so many cases where this doesn't work. If you are in the process of plugging something in, you *expect* to have to take some action. You're in the mind set that you'll need to take action to make the device work. Can't disagree strongly enough here. When you plug headphones into your laptop, the sound switches from the speakers to the headphones. No intervention. This should definitely be the same case with plugging in USB headphones. But speaker jacks are completely different to USB sound devices. You cannot use them as a comparable example here. I mean, if I've got some USB speakers which have a jack socket on the front of them (I'm looking at just such devices right now in front of me) and I plug in some headphones to the jack socket on my computer, I do not expect the sound to be moved across from playing on the USB device to my internal device and subsequently on my headphones when this happens. 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). I don't think I'm out of the ordinary here. And there are countless other scenarios where this just doesn't work OOTB. 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. 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@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
On 10-06-15 12:05 PM, Colin Guthrie wrote: 'Twas brillig, and Jeremy Nickurak at 15/06/10 16:31 did gyre and gimble: On Tue, Jun 15, 2010 at 01:40, Colin Guthriegm...@colin.guthr.ie wrote: I really don't think this is wise. There are so many cases where this doesn't work. If you are in the process of plugging something in, you *expect* to have to take some action. You're in the mind set that you'll need to take action to make the device work. Can't disagree strongly enough here. When you plug headphones into your laptop, the sound switches from the speakers to the headphones. No intervention. This should definitely be the same case with plugging in USB headphones. But speaker jacks are completely different to USB sound devices. You cannot use them as a comparable example here. I mean, if I've got some USB speakers which have a jack socket on the front of them (I'm looking at just such devices right now in front of me) and I plug in some headphones to the jack socket on my computer, I do not expect the sound to be moved across from playing on the USB device to my internal device and subsequently on my headphones when this happens. 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). I don't think I'm out of the ordinary here. And there are countless other scenarios where this just doesn't work OOTB. 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. I think the ability to say this is my preferred sound device would be ideal. So if that device gets plugged in it automatically becomes the output. You don't make your headset the preferred device, and you're happy. For me, I really want my good-sounding USB speakers to automatically work when I plug them into my (crappy-speakers-) laptop. The portability/sound quality tug-of-war causes me to be constantly fiddling with sound preferences. -Nathan ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
'Twas brillig, and Nathan Kidd at 15/06/10 17:18 did gyre and gimble: I think the ability to say this is my preferred sound device would be ideal. So if that device gets plugged in it automatically becomes the output. You don't make your headset the preferred device, and you're happy. For me, I really want my good-sounding USB speakers to automatically work when I plug them into my (crappy-speakers-) laptop. The portability/sound quality tug-of-war causes me to be constantly fiddling with sound preferences. What you want here is definitely something that will be supported. That's not the debate. The discussion is about what should happen by *default* the very first time a device is plugged in. I maintain that the new device should not change your setup and that, except in some special cases (like VoIP calls for Headset devices) the new device should be injected in at the bottom of the priority list of devices, not at the top. 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@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
On 10-06-15 12:38 PM, Colin Guthrie wrote: 'Twas brillig, and Nathan Kidd at 15/06/10 17:18 did gyre and gimble: I think the ability to say this is my preferred sound device would be ideal. So if that device gets plugged in it automatically becomes the output. You don't make your headset the preferred device, and you're happy. For me, I really want my good-sounding USB speakers to automatically work when I plug them into my (crappy-speakers-) laptop. The portability/sound quality tug-of-war causes me to be constantly fiddling with sound preferences. What you want here is definitely something that will be supported. That's not the debate. The discussion is about what should happen by *default* the very first time a device is plugged in. Mea culpa for not reading the whole thread first. -Nathan ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
On Tue, Jun 15, 2010 at 10:05, Colin Guthrie gm...@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. OTOH, if I've got my nice new A2DP bluetooth headset, and I associate it with my laptop, I probably immediately want all the fallback music taken off the crummy tinny speakers onto my headset, without intervention. Likewise for my home theatre system if I plug in there. I don't think I'm out of the ordinary here. And there are countless other scenarios where this just doesn't work OOTB. 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? 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) -- Jeremy Nickurak -= Email/XMPP: jer...@nickurak.ca =- ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
'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 gm...@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@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
On 16 June 2010 04:05, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Jeremy Nickurak at 15/06/10 16:31 did gyre and gimble: On Tue, Jun 15, 2010 at 01:40, Colin Guthrie gm...@colin.guthr.ie wrote: I really don't think this is wise. There are so many cases where this doesn't work. If you are in the process of plugging something in, you *expect* to have to take some action. You're in the mind set that you'll need to take action to make the device work. Can't disagree strongly enough here. When you plug headphones into your laptop, the sound switches from the speakers to the headphones. No intervention. This should definitely be the same case with plugging in USB headphones. But speaker jacks are completely different to USB sound devices. You cannot use them as a comparable example here. I mean, if I've got some USB speakers which have a jack socket on the front of them (I'm looking at just such devices right now in front of me) and I plug in some headphones to the jack socket on my computer, I do not expect the sound to be moved across from playing on the USB device to my internal device and subsequently on my headphones when this happens. 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). I don't think I'm out of the ordinary here. And there are countless other scenarios where this just doesn't work OOTB. 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. I think we're close to wanting the same thing, if you have specifically told the music to go to the USB speakers it should, all other streams/clients that have not * specifically* been told which device to use should switch to the new *local* (not network sinks) device... I think that covers the use you are suggesting while still keeping everything sane... My example - Buy new laptop install linux - Plug in USB speakers first time... all sound (including currently playing streams) moves to USB speakers - Plug in USB headset first time all sound moves to Headset, - Set music to output to USB speakers as preferred device - Unplug headset - Plugin headset, music stays on speakers all other sound moves to headset - Remove headset - Attach bluetooth headset, music stays on speakers all other sound moves to bluetooth headset - Remove USB speakers, music moves to bluetooth headset Thats what makes sense to me anyway Cheers Jason Taylor -- Weekends don't count unless you spend them doing something completely pointless. - Calven ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
'Twas brillig, and Jason Taylor at 15/06/10 22:59 did gyre and gimble: On 16 June 2010 04:05, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Jeremy Nickurak at 15/06/10 16:31 did gyre and gimble: On Tue, Jun 15, 2010 at 01:40, Colin Guthrie gm...@colin.guthr.ie wrote: I really don't think this is wise. There are so many cases where this doesn't work. If you are in the process of plugging something in, you *expect* to have to take some action. You're in the mind set that you'll need to take action to make the device work. Can't disagree strongly enough here. When you plug headphones into your laptop, the sound switches from the speakers to the headphones. No intervention. This should definitely be the same case with plugging in USB headphones. But speaker jacks are completely different to USB sound devices. You cannot use them as a comparable example here. I mean, if I've got some USB speakers which have a jack socket on the front of them (I'm looking at just such devices right now in front of me) and I plug in some headphones to the jack socket on my computer, I do not expect the sound to be moved across from playing on the USB device to my internal device and subsequently on my headphones when this happens. 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). I don't think I'm out of the ordinary here. And there are countless other scenarios where this just doesn't work OOTB. 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. I think we're close to wanting the same thing, if you have specifically told the music to go to the USB speakers it should, all other streams/clients that have not * specifically* been told which device to use should switch to the new *local* (not network sinks) device... I think that covers the use you are suggesting while still keeping everything sane... My example - Buy new laptop install linux - Plug in USB speakers first time... all sound (including currently playing streams) moves to USB speakers - Plug in USB headset first time all sound moves to Headset, - Set music to output to USB speakers as preferred device - Unplug headset - Plugin headset, music stays on speakers all other sound moves to headset - Remove headset - Attach bluetooth headset, music stays on speakers all other sound moves to bluetooth headset - Remove USB speakers, music moves to bluetooth headset Thats what makes sense to me anyway Why does the music move to the bluetooth headset in the final example? You seem to suggest that if the priority lists for music is as follows immediately before the BT headset is attached: 1. USB Speakers 2. USB Headset 3. Internal Audio But afterwards plugging in the BT Headset, it's not clear as to whether the list is: 1. USB Speakers 2. BT Headset 3. USB Headset 4. Internal Audio or 1. USB Speakers 2. USB Headset 3. BT Headset 4. Internal Audio Both lists would achieve the result you describe as the USB Headset is not currently plugged in. I presume you mean the first example, in which case I'd infer your logic for picking the insertion point of the new device as being immediately after the highest priority available device. This would thus cause no immediate change, but certainly ensures that it messes up any careful configuration the user does. If we were to even begin to entertain this approach, I'd suggest that the new device *must* appear at the end of the priority list, i.e. *after* Internal Audio. Any other setup is pretty much guaranteed to piss of people who want a configuration that stays the way they set it and probably also manages to disappoint the people who want the latest device to be the default too. So I'm not personally convinced, but we can see what others (specifically Lennart) think. For me it's the lack of transparency as to how things work that I'm most against, although it does obviously add to the complexity of implementation too. I'd be happy enough with a simple option of new devices enter priority lists at the top which defaults to off, but can be turned on if the user so desires. My only concern with such an option is that for the vast majority of people, it really matters not one jot as they'll only ever have maybe two or three devices, which really makes specifically coding for this preference something that almost doesn't seem worth it. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source:
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
Why does the music move to the bluetooth headset in the final example? You seem to suggest that if the priority lists for music is as follows immediately before the BT headset is attached: 1. USB Speakers 2. USB Headset 3. Internal Audio But afterwards plugging in the BT Headset, it's not clear as to whether the list is: 1. USB Speakers 2. BT Headset 3. USB Headset 4. Internal Audio or 1. USB Speakers 2. USB Headset 3. BT Headset 4. Internal Audio Both lists would achieve the result you describe as the USB Headset is not currently plugged in. I presume you mean the first example, in which case I'd infer your logic for picking the insertion point of the new device as being immediately after the highest priority available device. This would thus cause no immediate change, but certainly ensures that it messes up any careful configuration the user does. What I would like Music Streams have a user set rule of always go to USB Speakers, if the USB speakers not pugged in then follow the priority list. Priority list is the order in which I plugged devices in.. (this is local machine devices only) - Bluetooth headset - USB headset - USB speakers - Internal If a device is removed it should be removed from the priority list, so unplugging the USB headset gives - Bluetooth headset - USB speakers - Internal Plugging USB headset back in gives - USB headset - Bluetooth - USB speakers - Internal Devices which have a preferred device set should always use that device if available, else fall back to following the priority list I don't consider this magic from the point of view of the user.. its fairly simple sound moves to the device I just plugged in unless I've set up configuration to tell it not to I don't know if we are going to agree here :) You want the user to manually select devices, I want the user to be able to override a sane (IMHO) default device selection behavior I want to be able to tell my sister that all she has to do to use her headset is plug it in. At the moment I have to tell her to plug the headset in.. left click on the speaker icon, click settings, goto output tab, click the correct output, now restart what ever app your using /end rant Cheers Jason Taylor -- Weekends don't count unless you spend them doing something completely pointless. - Calven ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
'Twas brillig, and Jason Taylor at 13/06/10 22:59 did gyre and gimble: Here is my proposal: http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/ In my humble opinion Device by media.role is not that great.. it stand up for events, but it should really be be per client (application) The major use cases i have right now that suck... and are not solvable without prior knowledge of how pa works 1 - If I plug in my USB or Bluetooth headset the music does not change to headset like my analogue headset does... With your analogue headset music does not change to it, all output changes to it. I know what you're hinting at, but the two cannot be compared unless you just talk about all output. With my proposal, music could be configured to move to the new USB/bluetooth headset. 2 - If I plug in a USB or Bluetooth microphone apps like *skype* can not be set to use that mic without restarting skype? Incorrect. When PA is used, Skype detects it and uses only it. It (correctly) does not offer you the configuration choice inside Skype. It is mostly up to tools like gnome-volume-control/pavucontrol etc. to configure the Skype streams, but in the case of a USB or Bluetooth headset, the PA module module-intended-roles kicks in and automatically moves voip streams to headset devices. This currently works pretty well (I don't have to do any configuration after setting up my bluetooth headset for it to just work with Skype. It's quite nice, but not very transparent. If you read the link I sent through, I believe I proposed there (maybe it was afterwards on the list - can't quite recall) that module-intended-roles becomes a passive module that simply injects brand new (never seen before) devices into the appropriate place in the priority list for the appropriate role. That way it's more transparent to the user and the net functionality remains the same. 3 - There no way to easily set the media role or an app that dosn't have one (yes the all should have a role but they don't), pa could be doing better here using desktop files and the role should be saved.. PA *does* use .desktop files. That's what module-augment-properties does... 4 - Videos do not cork music No they don't. Currently the automatic corking is implemented by module-cork-music-on-phone. This could be made more generic with some kind of simple rules file that could be parsed at startup to allow video corks music. That would be kinda sensible IMO. By default I think pa should: - Move all inputs and outputs to any newly connected local device (ie usb, bluetooth whatever) that appears after pa has started (unless the per client device has been set of course) Perhaps, but I don't think everyone would agree here. I certainly would not be appropriate for my crappy bluetooth headset here. It's acceptable for phone streams, but really not for anything else. - There should be a simple UI for setting a clients default media role (if one has not been set), and this role should be remembered by pa This could be done, but I'd personally rather not do it. An alternative would be an independent database (like pci.ids or usb.ids) that could know which apps are which roles, that we can update via the web and bundle when we release, but I think letting users do this removes from the simplicity that should underlie this system. If the user cares that much, they can either edit the .desktop file or create a wrapper script/alias that sets the relevant env vars to allow for role to be forced. - Streams should inherit media role from the client if they don't have one set... ie firefox is set to video, so all its streams have a media role of video Not quite sure how easy this would be, but in theory if the client has a proplist, it should be easy to make any streams that client creates inherit that (I'd have to check to see if this is not done already!) - A module to cork music when video is playing Should be trivial to do (although depending on the options and combinations here it may be better to parse some simple rules (or just rename module-cork-on-phone and call it module-auto-cork or something and implement this extra rule (tho' I guess separate modules give users more control). Those 4 things would solve every problem I can think of and make pa function as I think 90% desktop users expect I think most points are valid. With the exception of the first one, the others are not technically that much related to routing (the role points are related if you assume most routing is role-based (at least initially)) and as such are probably orthoganal to the routing overhaul I suggest. Certainly worth keeping in mind tho'. 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/]
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
'Twas brillig, and Yves (theYinYeti) at 14/06/10 08:48 did gyre and gimble: Le 14/06/2010 01:59, Jason Taylor a écrit : I just realized I missed one other use case... pa has no concept of window order.. - With 2 streams of the same role (other then notification) are active the stream that has the higher client in the window stack should be the active stream, all other streams should be corked I'm not absolutely sure of what corked means, but it seems to mean paused. If so, I don't agree. Here's an example where I don't want anything to happen to current sound when another sound of the same nature begins: My son watches a cartoon on TV, the picture of which comes from the S-Video output of the PC (display :1 ); the sound is directed at the TV as well using sound card #2. Meanwhile, on the computer's screen (display :0 ), I watch a conference, the sound of which goes to the screen's integrated speakers through sound card #1. This setup is quite common with me. Even more often (but then roles are different I guess), the HiFi plays Deezer (good music) while the integrated speakers let me hear both the orator of the lengthy conference I'm attending, and the events' sounds of the little game I have alongside, for moments in the conference when there's nothing interesting being said. I definitely don't want any sound to ever be paused or stopped automatically. But then, maybe I'm not part of the normal users... I think you're probably right about being not part of the normal users, but that's not to say the problem isn't solvable. For example, each stream has the following property: window.x11.display = :0.0 It would be theoretically possible to make the cork rules only affect streams that are on the same display as the one that triggers them. e.g. a video on display :1 would not affect music on display :0 or similar. It obviously makes things more complicated, but it's theoretically possible if someone puts in the work! 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@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
