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

[Kaster, Kevin W]

Tanu,

Thank you for the information. Looks like I'll be getting my feet wet inside Pulseaudio, once we decide whether we need HFP or not :-).

Kevin

-----Original Message-----
From: Tanu Kaskinen [mailto:tanu.kaskinen at linux.intel.com]
Sent: Thursday, July 31, 2014 5:09 AM
To: Kaster, Kevin W
Cc: pulseaudio-discuss at lists.freedesktop.org
Subject: Re: [pulseaudio-discuss] Pulseaudio BlueZ sink is running but not producing audio sound

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
messages:

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

> Is Pulseaudio 5.0 compatible with Bluez 4.101?

Yes.

> 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...

--
Tanu

**************************************************************************************** Note: If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. ****************************************************************************************