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. 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. -- 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
