Guys<br><br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The API is not properly design for audio over hci that&#39;s why you are confused.
</blockquote><div><br>there are some parts of the dbus api that would be used even for the hci mode. Disconnecting the headset for example, since there is not an equivalent alsa call. Disconnect/reconnect will likely be handled in a single system gui that is outside the audio app.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">We could disable those concurrent method while in hci mode as they probably break
<br>the plugin stream, actually they normally affects only the rfcomm socket because<br>sco socket got duped in the process so plugin got its own reference that is not <br>affected by API calls, but anyway this is a not common behavior for a headset.
<br><br>btw, switching between audio device is currently done by changing its default device.</blockquote><div><br>we need a way to tell the plugin that the sco (or a2dp) fd has been invalidated, eg when disconnecting. This is broadcast over dbus and also communicated over the socket to the alsa client so the alsa plugin will do something sensible like use the wired audio. (similarly when the headset reconnects during stream playback--the fd is now available and the plugin needs to be told to re-request it)
<br><br>Brad<br></div><br></div><br>