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. > -----Original Message----- > From: Tanu Kaskinen [mailto:tanu.kaskinen at linux.intel.com] > Sent: Sunday, July 27, 2014 8:29 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 Thu, 2014-07-17 at 22:08 +0000, Kaster, Kevin W wrote: > > Hi, > > > > I'm having problems with a Pulseaudio BlueZ sink, and I don't know how > > to debug it further. My BlueZ sink appears to be running but it is not > > passing any audio to the BT headphones. > > > > Background: > > I am using BlueZ 5.19, Pulseaudio 5.0, DBus 1.8.4, ALSA lib 1.0.26. > > I am basically building a new distribution using Yocto based on Poky. > > So I have to pull all the pieces in myself, and I may have missed > > something or built in with the wrong switches. > > I am running everything as root (this is a deeply embedded system), > > including pulseaudio. I have seen the message about not running as > > root, but I also saw a note that running as --system doesn't support > > dynamic loading, and I didn't know if that applied to Bluetooth > > detection or not. So I'm open to changing this if someone can tell me > > the correct thing to do. But regular audio to the Pulseaudio ALSA sink > > works fine so I don't think that is the problem. > > The correct thing to do is to use --system. > Okay, I'll give that a whirl. > Dynamic module loading does apply to bluetooth. It applies to alsa too, but > only if you plug in new devices during runtime. > > Pulseaudio will print a warning, for security reasons, if you run it in system > mode without also disabling module loading. I don't think those security > reasons apply in your situation, or if they do, running as root to avoid that > warning is not any more secure. > > So, if you get this warning: > > Running in system mode, but --disallow-module-loading not set! > > then that's good, because it means that bluetooth won't be prevented from > working. > > > 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. 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? > > How can I debug this further? > > 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#>. 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. I also checked all of the volume and muting and they said they were good. > 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. > > -- > Tanu 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. Thanks, Kevin **************************************************************************************** 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. ****************************************************************************************
