Apparently bluez supports sending mp3 data directly to bluetooth stereo headphones, rather than using CPU taxing SBC compression encoding. This is especially good on the openmoko. In my experience, it can handle even high fidelity audio, but as soon as you start using the GUI or some other CPU intensive activity, it will start to skip hevily.
With much effort I've managed to convince gstreamer to send mp3 data directly to a2dpsink, and the performance has improved remarkably! And the CPU is no longer getting hammered. I can see why this encoding option is so ubiquitous among other cell phone music players. My problem now, is that I'm using the gst-launch gstreamer debugging command line tool to play my audio. This isn't good because it doesn't support basic things like pausing or seeking, and even if it did, the AVRCP signals from my headphone pause and play buttons wouldn't be registered unless it's listening to X for input events. Thinking back, I remember that there used to be an openmoko media player that used gstreamer, and it looked pretty nice and it was done up with GTK in the old om2007 style. Is that media player still around? Would it be possible to make it into its own project so that I can install it under debian without major hassles? (And also I'd like to upgrade it to support direct mp3 a2dp.) Or, do y'all have any alternative suggestions for me? (FYI: The way to test direct mp3 is like this: gst-launch filesrc location=<some mp3 file> ! mp3parse ! a2dpsink device=XX:XX:XX:XX:XX:XX ... You may also want to pass --gst-debug a2dpsink:5,avdtpsink:5 to it. I had to manually patch a problem where it was reporting 'joint-stereo' instead of just 'joint' from mp3parse... but I don't know, it may work under other distributions than Debian) -- Daniel Benoy http://daniel.benoy.name _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
