Ticket #1656 (closed defect: fixed)

Opened 6 years ago

Last modified 5 years ago

Bad A2DP performance

Reported by: Mercury Owned by: Nytowl
Priority: normal Milestone:
Component: Distro Version:
Severity: major Keywords:
Cc: fwendt, SimonKagstrom, montgoss Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible:

Description

I tried setting up A2DP.

First I bonded my freerunner with my headphones using instructions from here:
http://wiki.bluez.org/wiki/HOWTO/Bonding

Then I added an entry in asound.conf like this:


pcm.!default {

type bluetooth
device "AA:BB:CC:DD:EE:FF"

}


Then I followed some instructions on the openmoko wiki and ran a script like this:


#!/usr/bin/python
import dbus
bus = dbus.SystemBus?()
manager = dbus.Interface(bus.get_object('org.bluez', '/org/bluez'), 'org.bluez.Manager')
conn = manager.ActivateService?('audio')
audio = dbus.Interface(bus.get_object(conn, '/org/bluez/audio'), 'org.bluez.audio.Manager')
path = audio.CreateDevice?('00:15:0E:A0:63:5A')
audio.ChangeDefaultDevice?(path)
sink = dbus.Interface(bus.get_object(conn, path), 'org.bluez.audio.Sink')
sink.Connect()


It worked, but I got extremely bad performance. It was so choppy it was completely unlistenable. Maybe 5% of the sound made it to my ears.

I tried it with another A2DP headset, and I got the same results.

I don't know if I'm doing something wrong, if there's a bug, if there's a flaw in the freerunner, or if the chip isn't capable of the bandwidth needed for this?

Attachments

list_installed (41.0 KB) - added by Mercury 6 years ago.
I upgraded to 2008.8, and then upgraded to the unstable feed, and I'm still having the same performance. Is there a hardware issue with the Freerunner? Is there a way to test if the freerunner bluetooth bandwidth throughput and/or signal strength is sufficient for A2DP? I've attached my opkg list_installed

Change History

comment:1 Changed 6 years ago by Mercury

l2ping looked like this when I tried playing at 44100Hz sound sample rate:

root@lisa:/# l2ping 00:15:0E:A0:63:5A
Ping: 00:15:0E:A0:63:5A from 00:06:6E:17:24:C5 (data size 44) ...
4 bytes from 00:15:0E:A0:63:5A id 0 time 16.62ms
4 bytes from 00:15:0E:A0:63:5A id 1 time 34.33ms
4 bytes from 00:15:0E:A0:63:5A id 2 time 31.22ms
4 bytes from 00:15:0E:A0:63:5A id 3 time 41.30ms
4 bytes from 00:15:0E:A0:63:5A id 4 time 46.31ms
4 bytes from 00:15:0E:A0:63:5A id 5 time 26.58ms
4 bytes from 00:15:0E:A0:63:5A id 6 time 26.49ms
4 bytes from 00:15:0E:A0:63:5A id 7 time 29.40ms
4 bytes from 00:15:0E:A0:63:5A id 8 time 30.37ms
4 bytes from 00:15:0E:A0:63:5A id 9 time 36.55ms
4 bytes from 00:15:0E:A0:63:5A id 10 time 33.41ms
4 bytes from 00:15:0E:A0:63:5A id 11 time 35.38ms
4 bytes from 00:15:0E:A0:63:5A id 12 time 33.41ms
4 bytes from 00:15:0E:A0:63:5A id 13 time 32.40ms
4 bytes from 00:15:0E:A0:63:5A id 14 time 40.53ms
4 bytes from 00:15:0E:A0:63:5A id 15 time 45.44ms
4 bytes from 00:15:0E:A0:63:5A id 16 time 197.87ms
no response from 00:15:0E:A0:63:5A: id 17
no response from 00:15:0E:A0:63:5A: id 18
no response from 00:15:0E:A0:63:5A: id 19
no response from 00:15:0E:A0:63:5A: id 20
no response from 00:15:0E:A0:63:5A: id 21
no response from 00:15:0E:A0:63:5A: id 22
no response from 00:15:0E:A0:63:5A: id 23
no response from 00:15:0E:A0:63:5A: id 24
no response from 00:15:0E:A0:63:5A: id 25
4 bytes from 00:15:0E:A0:63:5A id 26 time 3809.00ms
4 bytes from 00:15:0E:A0:63:5A id 27 time 37.09ms
4 bytes from 00:15:0E:A0:63:5A id 28 time 34.14ms
4 bytes from 00:15:0E:A0:63:5A id 29 time 35.09ms
4 bytes from 00:15:0E:A0:63:5A id 30 time 36.10ms

And it looked like this when I tried it at 16000Hz

root@lisa:/# l2ping 00:15:0E:A0:63:5A
Ping: 00:15:0E:A0:63:5A from 00:06:6E:17:24:C5 (data size 44) ...
4 bytes from 00:15:0E:A0:63:5A id 0 time 10.78ms
4 bytes from 00:15:0E:A0:63:5A id 1 time 30.08ms
4 bytes from 00:15:0E:A0:63:5A id 2 time 34.22ms
4 bytes from 00:15:0E:A0:63:5A id 3 time 41.09ms
4 bytes from 00:15:0E:A0:63:5A id 4 time 27.22ms
4 bytes from 00:15:0E:A0:63:5A id 5 time 80.34ms
4 bytes from 00:15:0E:A0:63:5A id 6 time 10.36ms
no response from 00:15:0E:A0:63:5A: id 7
4 bytes from 00:15:0E:A0:63:5A id 8 time 10060.39ms
4 bytes from 00:15:0E:A0:63:5A id 9 time 2219.70ms
4 bytes from 00:15:0E:A0:63:5A id 10 time 28.56ms
4 bytes from 00:15:0E:A0:63:5A id 11 time 33.69ms
4 bytes from 00:15:0E:A0:63:5A id 12 time 34.57ms
4 bytes from 00:15:0E:A0:63:5A id 13 time 28.71ms

comment:2 Changed 6 years ago by Mercury

  • Version set to unspecified
  • Severity changed from normal to major

I tried the same bluetooth headphones on my Linux PC machines using the same methods, and a USB bluetooth dongle.

I got good performance at short range. (At long range, like 5 meters away, I get the same crappy performance, but I guess that's normal for bluetooth) Whereas my openmoko phone could literally be touching my headset and still get terrible performance.

I have yet to try my bluetooth dongle connected to my freerunner.

Has anyone else experienced this problem? I don't know if I'm alone in this. Is the freerunner just not designed for the level of bluetooth throughput that A2DP requires?

comment:3 Changed 6 years ago by fwendt

  • Cc fwendt added

comment:4 Changed 6 years ago by SimonKagstrom

  • Cc SimonKagstrom added

comment:5 Changed 6 years ago by montgoss

  • Cc montgoss added
  • Version unspecified deleted

I get slightly better performance than the OP, but still have issues. I noticed distance between the freerunner and headset has a large impact on the number of glitches while playing. Also, sample rate makes a big difference.

I ran some tests with the headset about 2.5 feet from my Freerunner. A song played at the lowered 16 KHz has just a few glitches and produces the following output:
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 16000 Hz, Stereo
6746 frames decoded (0:02:56.2), +0.6 dB peak amplitude, 36 clipped samples

If I play the same song at the same distance, but at the original 44.1 KHz, it's unbearably glitchy. I get:
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
6746 frames decoded (0:02:56.2), +0.6 dB peak amplitude, 187 clipped samples

I notice the worse it sounds, the higher the "clipped samples" number is. Are those clipped samples the glitches I'm hearing? Or is that clipping something else?

comment:6 Changed 6 years ago by andy

Clipped means that it got decoded / amplified / filtered beyond + or - 32767. It will cause a little "tick" sound usually. So this is enough to make the problem... try using switches in your decoder to "amplify" to -1dB or somesuch and see if it helps.

But the datarate for your raw data in the second case is pretty high, 1.4Mbits/sec sustained. I don't know much about Bluetooth to say if it makes trouble, EDR BT seems to provide 3Mbits/sec raw bandwidth so it isn't crazy if that is what we provide.

comment:7 Changed 6 years ago by montgoss

Following the thinking that it's a signal strength issue (since distance affects performance), is there a way to boost the signal? That would definitively confirm or disprove my theory.

Changed 6 years ago by Mercury

I upgraded to 2008.8, and then upgraded to the unstable feed, and I'm still having the same performance. Is there a hardware issue with the Freerunner? Is there a way to test if the freerunner bluetooth bandwidth throughput and/or signal strength is sufficient for A2DP? I've attached my opkg list_installed

comment:8 Changed 6 years ago by Mercury

I get similar performance to montgoss now too, though. At 16kHz it's actually tolerable if the phone is touching my headphones. (Kinda defeats the purpose of wireless.. I can't even put it in my front pocket, 6 inches away from the headphones, and still get quality audio)

I'm feeling pretty convinced there's a signal strength issue.

comment:9 Changed 6 years ago by Mercury

Wow. I got a big boost in performance by changing hcid.conf to have these lines:
lm accept,master;
lp hold,sniff,park;

comment:10 Changed 5 years ago by john_lee

  • Owner changed from openmoko-devel to julian_chu
  • HasPatchForReview unset
  • Component changed from unknown to Distro

comment:11 Changed 5 years ago by roh

  • Owner changed from julian_chu to Nytowl

maintainer change

comment:12 Changed 5 years ago by Nytowl

Has anyone tested this on an FSO based distro ?

comment:13 Changed 5 years ago by Mercury

I tried it on Debian, and the default debian configs don't have the lines I mentioned in an earlier comment in its hcid.conf .. so my A2DP headphones got some very weak performance.

Honestly I think this ticket should be closed since it was observed with bluez 3, and we seem to be moving toward bluez 4 now. Who knows if it'll even be a problem then, and the config lines that made such a big difference for me may not be present or needed then.

comment:14 Changed 5 years ago by Mercury

Also another major issue with A2DP performance is CPU usage. However bluez has a gstreamer plugin that can be used to send raw mp3 data, bypassing the CPU intensive SBC encoding and allowing mp3 decoding to take place in the headphones. I've gotten this working and it made a *massive* difference in performance.

Here's how to send direct mp3 with gstreamer's gst-launch:
gst-launch filesrc location=<some mp3 file> ! mp3parse ! a2dpsink device=XX:XX:XX:XX:XX:XX

I've only tested it under debian and it only works after a communication bug between mp3parse and a2dpsink gets fixed (I've submitted a report to debian) ... not sure if it works under the openmoko distribution or not.

comment:15 Changed 5 years ago by SimonKagstrom

I think it should be closed.

A2DP works fine in 2008.12 and FSO with Bluez3 (and probably bluez4, I have not tried), it's just a configuration issue. So someone that has access to it: Please close this bug report.

comment:16 Changed 5 years ago by Nytowl

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.