Hello all, we need some way to support BT headsets in FSO2. In old FSO it was done in ophoned... which is no more... Regarding the implementation Paul had an interesting discussion in #bluez channel:
----------------- 11-01-2010 10:04:04 [PaulFertser]: Hi :) Can anyone please read the backlog about the SCORouting option? It would be nice to fully understand the implications and alter OpenEmbedded-supplied config accordingly. 11-01-2010 10:11:08 [jhe] PaulFertser: the idea of the PCM routing flag is to tell pulseaudio/alsa/gstreamer/etc that "The SCO socket you've been given is essentially a /dev/null, so you need to use some platform specific way to get audio going to the BT chip" 11-01-2010 10:11:32 [Vudentz] PaulFertser, from the documentation: SCO routing. Either PCM or HCI (in which case audio is routed to/from ALSA). In other words, PCM means hardware routing and HCI means software. Usually you have PCM routing for embedded devices. 11-01-2010 10:11:34 [jhe] PaulFertser: i.e. it would break on a system that does respect the flag, e.g. pulseaudio that's compiled with nokia-specific defines 11-01-2010 10:14:31 [PaulFertser] jhe: what about the systems that can route both via PCM and HCI? 11-01-2010 10:14:42 [PaulFertser] jhe: how to do configure those? 11-01-2010 10:14:57 [PaulFertser] Vudentz: unfortunately, the documentation is highly misleading, i've read the code, see the backlog. 11-01-2010 10:17:33 [PaulFertser] jhe: because according to the docs if EEPROM of BC4 chip is set to route over HCI, it does so by default but can be switched temporarily for the next SCO connection to route over PCM. 11-01-2010 10:17:56 [PaulFertser] jhe: sorry, i can't provide the link to the relevant appnote right atm but if you need that i'll google it. 11-01-2010 10:18:33 [holtmann] PaulFertser: These are vendor specific CSR commands. We don't use them. 11-01-2010 10:19:04 [PaulFertser] jhe: moreover i can't see how to deal with multiple BT chips, when one is routing SCO over PCM and the other is doing so over HCI. 11-01-2010 10:19:06 [jhe] PaulFertser: right now it's not possible to change the setting during runtime 11-01-2010 10:19:19 [jhe] PaulFertser: not possible with the current implementation 11-01-2010 10:19:22 [PaulFertser] holtmann: i know. But i think you might do that someday if one needs that and prepares a decent patch, right? 11-01-2010 10:19:56 [jhe] PaulFertser: we'd be happy to review API change suggestions and patches though ;) 11-01-2010 10:19:57 [vudentz!i=vude...@bombadil.infradead.org: PaulFertser, afaik you can't really do both, I mean there is a real hire connecting the audio codec chip with bluetooth chip in case of hardware so it doesn't make much sense to use HCI in those case, not use PCM when there isn't a hire. 11-01-2010 10:20:02 [holtmann!n=holtm...@nikita.holtmann.net: It is CSR specific. Really bad idea actually since it will not work with any other chip. 11-01-2010 10:20:47 [PaulFertser] jhe: the setting as it is implemented currently seems somewhat pointless to me. I can understand you setting the flag in capabilities based on the setting. I can't understand why prohibit the usage of Headset.Play(), what additional benefit does that give? 11-01-2010 10:21:29 [PaulFertser] holtmann: well, true. But sometimes when vendor-specific tricks are beneficial, they can be used, right? 11-01-2010 10:22:37 [holtmann!n=holtm...@nikita.holtmann.net: I am not sure it is really a good idea here. However feel free to show patches and specification enhancements. And even more important real use cases. 11-01-2010 10:22:38 [jhe] PaulFertser: with the new D-Bus based audio API we could actually make this more dynamic and adapter specific. All we need is a new optional property for endpoint registration. Then the audio.conf parameter can go away. 11-01-2010 10:23:09 [PaulFertser] Vudentz: it might make sense in some hardware configurations. E.g. on freerunners we have bt chip connected to pcm of the audio codec and that way we can use it directly with GSM _and_ we might want to use the same headset for VoIP. 11-01-2010 10:25:01 [PaulFertser] jhe: so, what is the benefit of runtime check in Headset.Play() anyway? There's already a flag in capabilities, if the client uses Play() by mistake, well, it's client's mistake. 11-01-2010 10:28:00 [jhe] PaulFertser: iirc older kernels would crash if there wasn't someone consuming data from or producing data to SCO link 11-01-2010 10:28:39 [jhe] PaulFertser: so the idea was to have it kind of as a safety measure that you don't end up with bluetoothd having a HCI-routed SCO socket but no-one to read or write it 11-01-2010 10:29:06 [jhe] PaulFertser: but yeah, the real value of it can be debated. do you think the check does some specific harm then? 11-01-2010 10:30:46 [PaulFertser] jhe: well, the default configuration in bluez is SCO over HCI. And it's nice to alter the configuration as minimal as possible -- less pain for distro builders. But on openmoko freerunner the chip is configured (EEPROM setting) to use SCO over PCM. If the check wasn't in there we wouldn't care and call Play() from our telephony apps whenever needed. 11-01-2010 10:32:49 [jhe] PaulFertser: but you can control the SCO even without Play() 11-01-2010 10:34:42 [jhe] PaulFertser: probably the best solution would be to get rid of the Play method completely so that there'd only be just one interface for SCO control 11-01-2010 10:35:42 [jhe] PaulFertser: iirc that was the original intention but since there was some old maemo code using it we let it stay (but only when PCM routing was configured) 11-01-2010 10:36:09 [holtmann!n=holtm...@nikita.holtmann.net: PaulFertser: The value is a PS key setting and can be actually changed. In case of ROM chips you have to bootstrap them anyway. Since there is no EEPROM or any kind of persistent storage in the Bluetooth chip. 11-01-2010 10:38:37 [PaulFertser] holtmann: i tried changing PS key in the chips i use and it was persistent across power-cuts. I'm sure we do not bootstrap our chips in any way. 11-01-2010 10:39:57 [PaulFertser] jhe: i'm sorry to seem ignorant but i can't immediately see how to initiate an SCO over PCM connection without Play(). 11-01-2010 10:40:11 [PaulFertser] Over dbus 11-01-2010 10:40:13 [jhe] PaulFertser: using the unix socket interface that we have for audio 11-01-2010 10:40:52 [PaulFertser] Hm, dbus is actually handier to call from anywhere. 11-01-2010 10:41:01 [jhe] PaulFertser: i.e. request a stream using it and you get sco. send the IPC_STOP (or whatever it's called) or just close the unix socket and bluetoothd closes the SCO 11-01-2010 10:42:11 [jhe] PaulFertser: the whole unix socket based thing will go away in the future and become D-Bus based, now that D-Bus supports file descriptor passing 11-01-2010 10:42:39 [PaulFertser] jhe: but if we do not need SCO stream at all and we just want to initiate a connection to the headset so SCO is decoded and passed over the PCM interface? Play() method works ok for that. 11-01-2010 10:42:51 [jhe] PaulFertser: and even now you need the unix socket anyway if you're doing HCI routing, so it'd only give you a consistent interface regardles of whether you're using HCI or PCM routing 11-01-2010 10:43:17 [PaulFertser] jhe: sounds reasonable 11-01-2010 11:05:03 [PaulFertser] jhe: holtmann: big thanks for your patience and detailed explanations! :) ----------------- The interesting part is not to use the Play method, but the unix socket instead... at least until that one get's replaced with a different dbus API. -- Klaus 'mrmoku' Kurzmann _______________________________________________ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
