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

[Colin Guthrie]

'Twas brillig, and Tanu Kaskinen at 13/06/11 17:32 did gyre and gimble:
> 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.

Nice, thanks.

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

I think the profile switching is a good idea. I think Amanda (or other
folk on this list recently) were working on auto-profile switching
support based on module-intended-roles, so this would tie in nicely IMO.

Need to get a list of the various external patches in this regards
together so we don't reinvent things :D

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


Sounds reasonable.

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

Hmm, I see what you mean. It's not really particularly pretty, but
probably the easiest way around it.

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]