Brad Midgley wrote: > Jim > > The best fit for this older version is talking to the service via > d-bus. At one point I had python and d-bus working well enough to fire > off the audio service as in the example at > http://wiki.bluez.org/wiki/HOWTO/AudioDevices#python1 > > Combined with the right state file, you should get a bluetooth headset > working if the hardware is right. If it doesn't work, I would keep the > call and bluetooth play going and fiddle with mixer settings via > something like alsamixer to see if you can get any noise at all. > Perhaps run something that plays an mp3 at the same time and you'll > know if you find instead a way to get system audio out onto bluetooth. >
I already tried all that, including the python script. I've tried everything on the bluez wiki and the OM wiki. I think I have the .state file correct, no way of really knowing. I can't get anything to play through the headset be it a test wave file via aplay or gsm in a call. Short of reverse engineering both bluez and the audio driver and the kernel and the gsm drivers, I really don't see any other way of getting it to work, and I really don;t have an infinite amount of time to play with this stuff. Obviously OM never tested any of this, so its possible it is broken in the H/W, and could never work, who knows? Thanks for your help though. Is there a better version of bluez utils? I could easily build a new version, but I suspect I also need to build a new kernel if I go that route. There is no mention in bluez of chips routing the pcm audio directly to the audio card, so it is possible bluez doesn't support that option anyway? -- Jim Morris, http://blog.wolfman.com _______________________________________________ support mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/support
