co-existence of HFP and A2DP
12:07 < jhe> fdalleau: have you had time to think about the co-existence of HFP and A2DP and alternating between the two (listening to music, accepting a phone call, ending the call and resuming music)? 12:08 < jhe> fdalleau: I mean how would it be easiest controlled: through the upcoming plugin system (when plugin tells about an incoming call we suspend A2DP and bring up SCO), or through D-Bus, or something else? 12:08 < fdalleau> jhe, good point not really in fact, there is a white paper writen by the sig which explain interactions 12:09 < fdalleau> jhe, i've seen headsets sends a suspend just before opening sco 12:09 < jhe> fdalleau: yeah, though the paper you refer to recommends the AG side to do the suspending 12:10 < fdalleau> jhe, that's the only guaranted way of doing 12:10 < jhe> yep 12:10 < fdalleau> jhe, if one want to posing audio player 12:11 < fdalleau> jhe, to pause audio player, then there must be a system wide signal 12:11 < fdalleau> jhe, maybe it is possible to do the same than avrcp 12:11 < jhe> fdalleau: true. though I suppose it could also be done through the IPC mechanism we have to alsa/gstreamer couldn't it? 12:12 < jhe> fdalleau: actually we need to do that in anycayse since alsa/gstreamer/somethingelse needs to stop writing to the A2DP socket and receive a new SCO socket descriptor from the audio service 12:13 < jhe> or should it be handled as a separate IPC "client", i.e. a new connection to the IPC? 12:13 < fdalleau> jhe, in our case we have two different applications for phoning and music 12:14 < jhe> ah 12:14 < jhe> we might need to support both then 12:14 < jhe> which means extending the IPC protocol 12:15 < fdalleau> extending the ipc is still required, in particular if one wants to change headset while streaming 12:15 < jhe> true 12:16 < fdalleau> do you think the higher audio daemon could easily take care of stopping a2dp and starting hsp 12:17 < jhe> I don't know. elmarco has been pushing for that (letting pulseaudio handle all the controlling) but I'm not sure if we can finetune the behaviour and get it to be exactly like it's supposed to that way. 12:19 < fdalleau> pulse audio can do a lot of things, or be extended 12:21 < fdalleau> i think pulse audio can handle several parallel stream 12:22 < jhe> yep, though I suppose we'd need to have a native pulse plugin in that case and not us our stuff through the alsa plugin, right? 12:22 < jhe> to get full control of what's going on I mean 12:22 < fdalleau> well, i just thought about sco over pcm vs sco over hci 12:22 < fdalleau> can pulse audio take care of sco over pcm? 12:23 < jhe> in that case it would at least never see the actual audio data but just control the existence of the SCO connection 12:24 < jhe> elmarco: ping 12:24 < fdalleau> and what about hardware audio routers for extended fonctionality like fm radio ? can pa control this king of devices? 12:24 < fdalleau> s/king/kind 12:28 < elmarco> jhe: pong, lunch :) 12:48 -!- dwmw2_gone is now known as dwmw2_ULN 13:12 -!- fchevalier [n=fchevali@pat35-2-82-240-215-236.fbx.proxad.net] has quit ["Leaving."] 13:14 -!- mzb_d800 [n=mzb@ppp108-88.static.internode.on.net] has quit [Read error: 113 (No route to host)] 13:14 -!- mzb [n=ubernut@ppp108-88.static.internode.on.net] has quit [Read error: 104 (Connection reset by peer)] 13:14 -!- mzb [n=ubernut@ppp108-88.static.internode.on.net] has joined #bluez 13:14 -!- mzb_d800 [n=mzb@ppp108-88.static.internode.on.net] has joined #bluez 13:16 < develneubee> fdalleau: jhe: was out for lunch. u mean also do a g_free() before g_strdup, right ? 13:18 < fdalleau> yep 13:18 < develneubee> fdalleau: so the leak is when you dont get a CHUP/ATA. hmmm missed that. will make the change and send it to the list 13:19 < fdalleau> just call identify call twice and it leaks 13:20 < develneubee> fdalleau: right 13:21 < elmarco> jhe: handling the preemption automatically in the plugin system would mean implementing a hard policie in the plugin system 13:21 < elmarco> jhe: to tweak it, we would need to expose something like AcceptAutomatic(bool) or something like that 13:22 < elmarco> the alternative is to not implement those policy, but just expose the signal, 13:23 < elmarco> in that case we can describe in a higher-representation what will be the side effect of accepting a call: it would stop the audio from being played on SCO 13:23 < elmarco> on A2dp sorry 13:24 < elmarco> otherwise, this is implecitely hidden in a hardcoded policy, specific to your domain (bluetooth audio devices) 13:25 < elmarco> Sure pulseaudio can do the management of this, but it could be something else. Wether or not it's part of pulseaudio is a matter of convenience 13:27 < elmarco> I would personnaly prefer to have a solution where you can take decision, not only about PulseAudio context, but other informations, such as authetication, usage of the device, performance, system resources.. 13:28 < elmarco> We can try to express all our needs in PA, but then it start to be not really the role of PA anymore, IMHO 13:28 -!- thiagoss [n=thiago@150.165.63.86] has joined #bluez 13:28 < develneubee> jhe: fdalleau: here is the updated patch http://en.pastebin.ca/868328 will send it out to the list 13:29 < fdalleau> elmarco, if not in bluez, and not in pulse audio, then where ? 13:29 -!- k-s [n=gustavo@189.70.130.103] has quit [Read error: 113 (No route to host)] 13:33 < elmarco> fdalleau: currently, there is lot of ad-hoc policy daemon everywhere: zaurus, qtopia, maemo, olpc, ..... 13:33 < elmarco> having a closed source PA plugin or a closed source daemon does not make a lot of difference to me 13:34 < elmarco> in order to solve this issue of expressing policies in a common framework, ohm was started 13:34 < elmarco> I don't say ohm is perfect, far from being 13:34 < elmarco> but it's the place where people gathered to try to find solution to that pb 13:35 < elmarco> there is severa design issues in OHM/vs HAL and session/system integration 13:35 < elmarco> + ohm does not really handle a "request" or a pluggable policy 13:35 < elmarco> so this is still on-going work :)
