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

[Tanu Kaskinen]

On Wed, 2011-06-15 at 10:46 +0800, Lin, Mengdong wrote:
> > Just pass the sco-source and sco-sink arguments to
> > module-bluetooth-discover.
> 
> Can I set the two parameters for module-bluetooth-discover in
> "default.pa" ? I've not found an example to pass parameters via
> "default.pa" ;-( 

Doesn't default.pa itself contain examples of parameter passing?

load-module module-bluetooth-discover sco-sink=name.of.the.alsa.sink sco-source=name.of.the.alsa.source

> > > -          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.
> 
> for Maemon, the "sco-sink" and "sco-source" are created by
> module-alsa-card before Bluetooth device is connected, right?

Well, so far we have loaded the devices without module-alsa-card, that
is, we have loaded module-alsa-sink and module-alsa-source directly in
system.pa.

> Is "sco-sink" a different sink from normal ALSA sink? Or they are the
> same ALSA sink and so routing is not needed when a Bluetooth HSP
> headset is connected?

It's a separate sink - if I remember correctly, on N900 both the
"normal" alsa sink and the sco sink were provided by the same card, but
different devices within that card, ie. hw:0,0 and hw:0,1, respectively.
I believe it's up to the kernel driver to decide how to represent the
devices in the userspace.

> When the module-bluetooth-device is initialized to HSP profile, it
> just stores "sco-sink" and "sco-source" and does not notify
> module-alsa-card to prepare for data transport (see init_profile ->add
> sink & add source). So how can module-alsa-card know it shall make
> "sco-sink" and "sco-source" ready for data transport?

What do you mean? Someone tells the module-alsa-card to switch the
profile, and the profile configuration tells how to load the alsa
devices, just like with any other profile change. What else is there to
know?

> It would be nice to load those dynamically. How can the
> module-bluetooth-device find the module-alsa-card and let it change
> profile and created new sink/source for HSP?

The alsa card name could be provided as a module argument to
module-bluetooth-discover, which would pass it on to
module-bluetooth-device.

> And where can I find the profile list of "module-alsa-card"?
> I want to check whether there is a profile for alsa to support
> "Bluetooth hsp".

Ah, so you want to do something very generic, ie. you don't even know
when writing default.pa whether there is a separate sco card available?
Maybe put some property to the card's property list that says which
profile name identifies the hsp profile - if it's missing, then the card
doesn't have such profile. pa_core.cards contains all cards, so you
could iterate through them and see if any of them have the magic
property set. I don't know what you should do if there are multiple sco
cards available, but I think that should never happen anyway, so picking
the first one found should be good enough.

> Are all the Maemo's changes merged to MeeGo? Including your fix for
> volume control? We want to study the code.

You're the one working on Meego :) I don't know what you have merged.

Our patches are available at
http://meego.gitorious.org/maemo-multimedia/pulseaudio/commits/patches
(which reminds me that I should push the latest patches there again -
the last update seems to be from April).

The volume control hack is this:
http://meego.gitorious.org/maemo-multimedia/pulseaudio/commit/ddad805874dbe3d1e6e0cb25c80aedf412ce373d

It seems that I described the problem wrong earlier. The problem wasn't
that the set_volume callback was set while the PA_SINK_HW_VOLUME_CONTROL
flag was not set, it was the other way around. So set_volume wasn't set,
but PA_SINK_HW_VOLUME_CONTROL was.

-- 
Tanu