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)
