On Fri, 2012-05-04 at 11:49 +0200, Dalleau, Frederic wrote: > Hi Tanu, > > On Fri, May 4, 2012 at 11:33 AM, Tanu Kaskinen <tanu.kaskinen at digia.com> wrote: > > On Fri, 2012-05-04 at 11:11 +0200, Dalleau, Frederic wrote: > >> Hi Tanu, > >> > >> On Fri, May 4, 2012 at 6:23 AM, Tanu Kaskinen <tanuk at iki.fi> wrote: > >> > On Thu, 2012-05-03 at 18:17 +0200, Fr?d?ric Dalleau wrote: > >> > About the third patch - do you have module-suspend-on-idle loaded? If > >> > so, why doesn't it suspend the source? If the source doesn't go to the > >> > IDLE state when all its outputs are corked, then that's a bug. If the > >> > source does go to the IDLE state, but module-suspend-on-idle doesn't > >> > suspend it, then that's a bug too. > >> > > >> > >> That's chicken egg problem, the source never goes to idle because > >> the loopback has a source-ouput using it. And the source-output is not corked > >> because the source is not suspended. > > > > Ah, right, I understood the point of the third patch wrong. So the > > scenario is that the bluetooth state changes from PLAYING to CONNECTED > > without Pulseaudio asking for it? What's the use case? Does it mean that > > while the device supports the A2DP_SOURCE profile, it's not usable right > > now? I think changing the card profile to "off" would be the right > > reaction. Ideally the routing policy would get a signal that "this port > > is not available right now, but it's worth trying again later", but > > there's no infrastructure for that yet. > > > > Yes it's exactly that, > I have two bluetooth adapters, and they are paired together. I'm using pulse > to send A2DP from one to the other. And then loopback to the speaker. > If I send a small sound, then the A2DP source will suspend on idle after > a few seconds. Then the A2DP sink (which is the pa_source used in the loopback) > has no data to play. And the loopback module fills the screen. Ok, that's a bit different use case than I thought it was. I didn't realize that the A2DP streaming is mostly controlled by the sending end. Is it so that the receiving end can't start the playback at all? If it's so, then my description of the "ideal" handling was wrong, because it's not worth to "try again later" without the sending end initiating the streaming first. This makes things simpler, and there is less infrastructure missing. The main thing that is missing is ports on bluetooth cards. So, ports have the concept of being "available" or "unavailable". When the bluetooth state changes to PLAYING, then module-bluetooth-device should mark its A2DP_SOURCE port as available. When the bluetooth state changes back to CONNECTED, the A2DP_SOURCE port should become unavailable. The hypothetical routing policy should then react to those available/unavailable events and do something sensible. For now, I think it still makes sense to change the profile to "off" when the device state changes from PLAYING to CONNECTED. Maybe the bluetooth-policy module (that has been waiting for review for a long time...) should change the card profile automatically to "a2dp_source" when the device state changes to PLAYING? -- Tanu
