[pulseaudio-discuss] Pulseaudio BlueZ sink is running but not producing audio sound

Tanu Kaskinen tanu.kaskinen at linux.intel.com
Thu Jul 31 02:08:36 PDT 2014

On Tue, 2014-07-29 at 16:31 +0000, Kaster, Kevin W wrote:
> Hi Tanu,
> Thanks for replying!
> By the way, this post is starting to get pretty long. Should I pair it
> down to the active parts or just leave it all? I haven't been able to
> find etiquette for this mailing list.

Trimming to only active parts is good.

> > > I have a basic /etc/asound.conf file which just specifies that the
> > > default ALSA PCM and CTL use the pulse plugin.
> > >
> > > Problem:
> > > When playing audio to the BlueZ sink, it looks like it is running
> > > properly, is not muted, has 100% volumes, and I can see the latency
> > > bouncing around at reasonable numbers. The Pulseaudio messages in the
> > > system log say it is streaming audio over A2DP. hcidump says ACL
> > > packets are being transmitted. But no audio comes out of the sink.
> > >
> > > What could be wrong?
> >
> > Broken headset?
> >
> I wondered that :-) but I tested it under Ubuntu and it works fine. I
> also went back to Bluez4 and the ALSA Bluetooth sink, and it works
> fine.
> Which brings up some additional questions. I tried to use Pulseaudio
> 5.0 with Bluez 4.101, but it didn't work. Pulseaudio wrote log
> messages that showed it knew the card was there, but it would never
> create the sink or even the card. There were no error messages and the
> bluez4 versions of the pulse bluetooth module were present.

This sounds like the device was not connected. After pairing, PulseAudio
will see that the device exists, but PulseAudio won't create a card
object before some of the audio profiles of the device become connected.
PulseAudio does not handle the connection, that's done by other tools (I
use Gnome's default bluetooth tool for that).

When the device gets connected, there should be this kind of log

Device /org/bluez/blah interface org.bluez.AudioSink property 'State'
changed to value 'connected'

> Is Pulseaudio 5.0 compatible with Bluez 4.101?


> This is important because we may need to support HSP/HFP, which I
> understand is still not possible with Bluez5?

Correct, not possible with unmodified PulseAudio 5.0.

> > Some ideas:
> >
> > Record from the bluetooth sink monitor to check whether the audio is muted
> > at that point:
> >
> >     parecord --device=bluez_sink.00_02_3C_43_4A_09.monitor > test.wav
> >
> > If it's muted, then the problem is somewhere before the bluetooth sink.
> I tried this. I didn't get any audio. But I don't see how the problem
> could be before the bluetooth sink, since I was playing directly to
> the bluetooth sink using paplay -d<sink#>.

Even though it might feel impossible that paplay would be playing
silence, it's still good to verify that whatever is played to the
bluetooth sink is valid audio.

> Actually I wasn't sure this was a valid test, since the sink accepts
> audio in but sends out bluez data packets, so I didn't know if
> the .monitor would actually produce audio.

The monitor will copy all audio that is fed to the bluetooth sink. If
you don't get any audio (not even silence) when recording from the
monitor, that means that the sink is not consuming any audio, i.e. it's
stuck. I don't know what data hcidump is showing, because apparently at
least PulseAudio isn't writing anything to the bluetooth socket.

> > If it's not muted, maybe you can investigate the data that hcidump produces.
> > Is it silence? I don't know how hard it is to interpret that data, though. You
> > could also try another headset to see if the problem is specific to the
> > headset.
> Right, that's one of my problems, I don't know how to interpret the
> hcidump data. I see that once pulse audio sets up the sink, there are
> constant messages flowing, so it's hard to know if anything changes.
> So I'm still stuck. Is there any deeper debugging available from Pulse
> or the pulse bluetooth module? (besides getting into the source, which
> I may have to do...). How about a good resource for debugging the
> Bluez side of the equation (I can't find anything on that)? I can see
> the bluetooth log but it tells me everything is working great. So I
> tend to suspect the Pulseaudio bluetooth sink simply isn't sending
> audo data, but I don't know how to check that. Or what to do if it
> isn't.

It indeed looks like pulseaudio isn't sending any audio. One way to
check it would be to add a log message to module-bluez5-device.c where
pa_write() is called. I don't know how to further investigate this -
maybe you have to hack on the kernel driver to figure out what's
happening or something...


More information about the pulseaudio-discuss mailing list