On Wed, May 15, 2013 at 9:00 AM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi Scott, > > On Wed, May 15, 2013 at 6:33 PM, Scott James Remnant > <keybuk@xxxxxxxxxxxx> wrote: >> It's still not fully clear to me how the state could be handled. For >> example, the following: >> >> We only acquire the transport stream when we have actual sound to be >> played, and once we've finished playback we release the transport >> stream again. In most circumstances this seems correct, and matches >> what we see on other platforms - with a suspend being sent to the >> device, and a start being sent when we have more sound to play. >> >> What I can't figure out is what we're supposed to do in the case where >> the device sends the start (state goes to pending) when we _don't_ >> have any sound to play. >> >> Are we still expected to acquire the transport stream? What happens if we don't? > > No top posting, please. > I wasn't replying to anything particular in your message > The headset controlling the A2DP stream like this is normally a bad > behavior/implementation, it should be using AVRCP Play/Pause, but > anyway it is possible that the headset takes over the control in fact > I remember someone trying to use those commands to do some kind of > audio transfer like in HFP. > > Anyway the answer for your question about pending state is probably > don't Acquire if you wont gonna use it, the start will fail and the > stream will stay suspended, you could also attempt to assume control > and Acquire the stream but if this is to work like audio transfer the > headset wants to override the routing so the speakers are used > instead. The device appears to sulk and drop the ACL entirely :-/ -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
