[pulseaudio-discuss] How to use "sco_sink" and "sco_source" in the bluetooth device module?

[Tanu Kaskinen]

On Sun, 2011-06-12 at 19:59 +0800, Lin, Mengdong wrote:
> Could someone tell me how to use "sco_sink" and "sco_source" in the
> bluetooth device module?
> 
> Because of hardware restriction, our bluetooth driver cannot handle
> HSP data transport. We want use an ALSA device's sink and source for
> BT HSP transport. It seems that by passing parameters to initialize
> the Bluetooth discover and device module, a bluetooth device can use
> external "sco-sink" and "sco-source" for HSP data transport.
> 
> My questions:
> 
> -          I can set the ALSA sink & source as the "sco-sink" and
> "sco-source", right? If yes, how can I set "sco-source" and "sco-sink"
> names as the parameter to load Bluetooth discover module in the
> default script for my platform?

Just pass the sco-source and sco-sink arguments to
module-bluetooth-discover. I noticed that the module still had some
instances of #ifdef NOKIA left, so you'll either have to compile
Pulseaudio with NOKIA defined, or apply the patch I just sent to the
mailing list that removes the ifdefs.

> -          Since "sco-sink" and "sco-source" are not dynamically
> created, so I cannot routing inputs/outputs to them by hook the
> "SINK-PUT" or "SOURCE-PUT" event, right?

Right. It would be good to make it possible to load those dynamically,
though. One possibility would be to load module-alsa-sink/source from
module-bluetooth-device when the hsp profile is activated. Or if the
card is managed by module-alsa-card, then module-bluetooth-device could
switch the card profile so that the appropriate devices get loaded.

> -          When can I move sink inputs or source outputs to the
> "sco-sink" and "sco-source"? Their state changes outside of the
> Bluetooth device. How are their state change synchronized with BT
> headset connection and disconnection? In BT device module,  I saw both
> "start_thread" and state change hook of "sco-sink" and "sco-source"
> call "sco_over_pcm_state_update" to setup data transport. So they can
> change to IDLE state at any time?

I don't know the module-bluetooth-device code terribly well, but I'd
guess that when the card profile is set to hsp, the module somehow sets
things up so that the sco-sink and sco-source are ready to process
streams. So maybe the routing logic should connect to the
PA_CORE_HOOK_PROFILE_CHANGED hook?

> -          Is there any extra work for the Bluetooth device or the
> device providing actual "sco-sink" and "sco-source" to do?

Sorry, what kind of work do you mean? I don't really understand the
question.

> -          Has the usage "sco-sink" and "sco-source" been verified on
> any platform?

Yes, like Luiz said, Maemo devices use it. Maemo doesn't use the vanilla
Pulseaudio upstream version, though, and I expect that the current git
version won't work out-of-the-box. There's not much missing - the only
thing that comes to my mind is one assertion in sink.c, if I remember
correctly, that has been relaxed, because otherwise the HSP volume setup
doesn't work.

module-bluetooth-device replaces the alsa sink's volume callbacks with
its own versions, and that causes problems because the alsa sink thinks
that it doesn't have hardware volume control, yet the volume callbacks
are set which should happen only when hw volume control is available.
I'd solve this so that module-bluetooth-device puts the callback
function pointers available in the pa_core.shared hashmap, and
module-alsa-sink gets the keys to the hashmap as module arguments and
then fetches the callbacks from the hashmap using those keys. That way
module-alsa-sink is aware of that in fact it does support hardware
volume control, it just does it in a different way than usual.

-- 
Tanu