[pulseaudio-discuss] Clicks or buzzing on Bluetooth

[Jim Carter]

Versions: SuSE 10.2, kernel 2.6.18.8
PulseAudio 0.9.6, xmms-pulse 0.9.3
Bluez-utils 3.7, a2dpd from CVS, xmms 1.2.10
Hardware: Dell Inspiron 6400, Intel Core Duo T5600 at 1.83 GHz;
Bluetooth: Broadcom BCM2045 in Dell transceiver (USB ID 413c:8126)

In the first test I'm using xmms to play music, using its esd
(Enlightened Sound Daemon) output plugin.  The source is a media server
on the local net, which sends out files ripped at 44100 Hz, either Ogg
Vorbis or MP3 (same behavior for both).  Sinks are either internal
speakers, or a Motorola HT820 Bluetooth headset (A2DP protocol).  The
sinks expect, and get, s16le 2ch 44100Hz.

After I use "move-sink-input" to move the input to the
Bluetooth (A2DP) ALSA device, the music is sent successfully to the
headphones, but accompanied by a continuous pulse train which could be
described as "clicks or buzzing".  It's at about 15 to 20 Hz.  It's
always there (not intermittent).  Its volume is proportional to the
music volume.  The music is at the expected pitch -- no chipmunk voices.
(In other words, we don't have an input at 44100 Hz, a sink at 48000 Hz,
and forgotten resampling.)

The pulse train is absent in these cases:  Using aplay to play a local
WAV file directly to the alsa:a2dpd object (no PulseAudio or ESD).
Using xmms -> ESD to play on a2dpd (Bluetooth).  Using xmms ->
PulseAudio (ESD plugin) to play on internal speakers or wired
headphones.

Without being able to prove anything, I interpret the pulse train like
this: On every (something) there is a delay, and while waiting for the
next batch the headphone plays silence, producing the pulses I hear.
The step from the last nonzero sample in the batch, to silence, and then
to the first nonzero sample in the next batch, would be proportional
statistically to the loudness of the music.  The MTU of the Bluetooth
connection is 1017 bytes as reported by hcitool, and my A2DP bitpool is
32, which would result in about 53 MTU-sized chunks per second, so the
pulses are not one per packet.  However, quoting from "man 7 pipe",
writing over 4096 bytes to a pipe may be non-atomic, and comments in
source code and forum postings suggest that a batch size of 4096 bytes
is used by PulseAudio when sending to ALSA devices.  It's quite
believable that there is one pulse every 4096 bytes.  

CPU starvation is not the issue: this machine has dual cores and there
were no competing processes.  Even with verbose=1, pulseaudio does not
report on syslog or stderr that it has reniced or obtained SCHED_FIFO;
however, it is at nice -15.  (I can't tell if it really did get
SCHED_FIFO.)

I notice that when I did "load-module module-alsa-sink sink_name=a2dpd
device=a2dpd", there was a brief pause (0.25 sec?) in the sound, which at
the time was being played on alsa:hw:0,0.  

The second test was nearly the same except using the PulseAudio plugin
for xmms.  The pulse train was not there!

However, when I play http://kusc-pc-stream.usc.edu:2345/kuscaudio96.mp3
which is at 32000 Hz, the same pulse train is back.  This stream is
compressed at I think the default quality level, giving 96 kbaud.  The
same behavior is seen on the 32 kbaud version (extremely aggressive
compression).

Does anyone have any idea what's going on, or where I should look to get
rid of this pulse train?

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: jimc at math.ucla.edu  http://www.math.ucla.edu/~jimc (q.v. for PGP key)