On 09/04/2013 07:57 PM, Felipe Tonello wrote: > Hi David, > > On Fri, Aug 30, 2013 at 11:22 PM, David Henningsson > <david.henningsson at canonical.com> wrote: >> On 08/30/2013 06:54 PM, Felipe Tonello wrote: >>> Hi David, >>> >>> On Fri, Aug 30, 2013 at 6:00 AM, David Henningsson >>> <david.henningsson at canonical.com> wrote: >>>> On 08/28/2013 07:15 PM, Felipe Tonello wrote: >>>>> Hi David, >>>>> >>>>> On Wed, Aug 28, 2013 at 5:38 AM, David Henningsson >>>>> <david.henningsson at canonical.com> wrote: >>>>>> On 08/27/2013 07:06 PM, Felipe Tonello wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On Tue, Aug 27, 2013 at 12:27 AM, David Henningsson >>>>>>> <david.henningsson at canonical.com> wrote: >>>>>>>> On 08/26/2013 08:15 PM, Felipe F. Tonello wrote: >>>>>>>>> From: "Felipe F. Tonello" <eu at felipetonello.com> >>>>>>>>> >>>>>>>>> This fixes a bug when switching profiles under ALSA UCM. If a jack, hence a >>>>>>>>> port, was previsouly active, when PA performed a profile switch, the jack >>>>>>>>> would continue to be available but not active. >>>>>>>>> >>>>>>>>> This patche ensures that it activates a port if a jack is previously connected. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> but I'm not sure this is the right way to do it. >>>>>>>> >>>>>>>> It feels like setting the active port is more like something for a >>>>>>>> policy module (e g module-switch-on-port-available), rather than being >>>>>>>> hardcoded in the module itself. >>>>>>> >>>>>>> With today's implementation it doesn't work, since if you switch >>>>>>> profiles the jack won't change its state, so >>>>>>> module-switch-on-port-available will not notice that. >>>>>>> >>>>>>> What it could be done is to ensure when you create a sink/source, to >>>>>>> report jack state, but this is a local function in alsa-module-card. >>>>>>> It would need more hack to make it work. >>>>>>> >>>>>>> Also, this is not hardcode the port, since the sink/source it self >>>>>>> does that, it checks if someone else set active_port before, otherwise >>>>>>> sets itself. >>>>>>> >>>>>>> IHMO this patch is less intrusive. >>>>>> >>>>>> Even if a jack is available, it does not mean that the port should be >>>>>> activated, unless you have a policy module saying so. It's the policy >>>>>> module that causes port switches in the first place. >>>>> >>>>> Ok. Then IMO the policy module should say so :) Because as a user, it >>>>> doesn't make sense when it's listening to a music with a headphone and >>>>> then when it places a call the sound goes to the speaker. >>>> >>>> OTOH, if you're playing back through the speaker, and make a call, you >>>> likely want the sound to switch, to go through the earpiece speaker >>>> instead of the main speaker. >>>> >>>> And where do you want your ringtone if you have headphones plugged in? >>>> Perhaps through both the headphones and your speaker? >>>> >>>> Etc. It's not that simple - which is why I want this functionality in >>>> policy modules rather than hard coded. >>> >>> Ok, it makes sense. But to be realistic, PA doesn't support Voice Call >>> mode smoothly anyway. At least when using ALSA UCM. >> >> We have voice call support in Ubuntu Touch, Arun is doing Voice Call >> support in another way, and PulseAudio has been used in phone projects >> in the past (Nokia N9). I'm not sure which implementation(s) that will >> make it in, but I'm happy to upstream mine if there is interest from others. > > Are those devices using PA vanilla? Which version? If so how can I > make good usage of PA with Voice Call mode? I'm using UCM today to > make it easier. So I have a profile with QT VoiceCall (which it seems > that PA doesn't care) that opens a dumb pcm device that does the > routing in the codec level. Then I have to write dumb data to this > sink so it doesn't suspend. I know that's not the appropriate > solutaion and I believe is causing problems with the > module-stream-restore. So, as for what I'm currently doing, you can see the code here: http://bazaar.launchpad.net/~ubuntu-audio-dev/pulseaudio/ubuntu/files/head:/debian/patches/ ...and look at the patches 0201-0204. As I use the Audio HAL for helping with the voice calls, I don't need the dumb PCMs. I haven't upstreamed them yet for two reasons - first is that I'm still working on them (it's not totally finished), and second, I'm not sure we have much review bandwidth right now anyway. As for PCMs that don't need to suspend, Tanu had one patch the other week and Arun had another a few weeks earlier, so I was hoping they would synchronise their efforts and come up with something that would work for both. Sounds like many people are interested :-) > (...cut...) > >> >> However, module-switch-on-port-available was more or less written with >> just desktop in mind, perhaps just because phones are more complex. And >> it's expected to be superseded/obsolete once we have the node routing >> system in place and working, but nobody knows how long that will take. >> >>> Then module-switch-on-port-available, probably find_best_port(), >>> should be more smart about choosing ports. It should use >>> sink/source->active_port just as an hint, testing other stuff (like is >>> a jack connected?) and if no other port was found, use active_port. >> >> You seem to distinguish between "jack connected" status and "port >> available" status? But the port availability status should always >> reflect whether the jack is connected or not, so I don't understand why >> you want to go after the "jack connected" status from the policy module. >> Or am I misunderstanding you? > > Yes, I understand that. It's true but don't you agree with me that if > you have a Headphone and Speaker port, if the jack is connected, both > ports will be available, right? If so, we should give priority to the > headphone. Thus we need to check if the port has a jack associated > with. No; if you want to prefer headphone over speaker and they have the same availability, you should do that by setting the priority - in ucm terms, this translates to the PlaybackPriority key. Then that should work with module-switch-on-port-available as the code is today (i e, PA git master). Another method could be to set the speaker's availability to unknown; but that might be ugly, if we really really need a method to indicate that something is *always* available to the policy module, perhaps we should add that as a new PA_AVAILABLE_* enum, but that could potentially break existing applications, so I want to avoid that if possible. > (...cut...) > >>>>> >>>>> Let me know if you want anything else? Because I can send a patch set >>>>> having both fixes. >>>> >>>> But if we have a working module-switch-on-port-available, we don't need >>>> any hint from the alsa module. Right? >>> >>> Yes, I think. So at a first point I would like to add jack support in >>> module-switch-on-port-available. I know that are probably much other >>> use cases, but those can be added later, right? We just need to do >>> something that can easily scale. >>> >>> What I suggest, like I said above, is to use active_port as a hint >>> only. It will check for other policies, such as jack is connected, and >>> then make a decision. What do you think? >> >> I think that the ALSA module should set the port's availability based on >> jack connection status. > > Which already does, right? Correct. > >> >> The policy module should set active_port based on port availability, >> priority, and possibly other stuff (like e g, if the user has selected >> speaker-phone mode or not). > > Let's do a priority list here so we can implement that properly. I > would say the following: > 1: port availability > 2: is port associated with a jack? > 3: priority > > That's for the use cases we have for today. > > What do you mean by speaker-phone mode? In many phone applications, there is a button which you can press, where the output switches from the earpiece speaker to the main speaker. http://en.wikipedia.org/wiki/Speakerphone -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
