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
