[pulseaudio-discuss] [BUG] Using bluez 5.5 & pulseaudio a bluetooth headset cannot be used as a recording device.

[Tanu Kaskinen]

Please use the "reply-to-all" functionality of your mail client. I added
pulseaudio-discuss back to CC once again.

On Fri, 2013-05-31 at 12:55 +0200, Alexander Winnig wrote:
> Thanks for your efforts.
> > Some notes about the video:
> >
> > At 1:21 the available sinks and sources only include the auto_null sink
> > and its monitor source. Why isn't the RPi's own sound card getting
> > detected? Well, let's not worry too much about that
> It used to. But I thought that raspberry's pulseaudio and bluez - 
> versions were too low and some people said that newer versions worked 
> with bt-headsets I configured, made and made-installed pa and bluez, 
> which was a pain.
> 
> > At 4:23 we see that there still isn't other sinks than auto_null. Either
> > the bluetooth card profile is "off", or PulseAudio had problems with
> > creating a sink for the headset.
> See above.
> >
> > Conclusion: remove the .asoundrc file.
> Done.
> 
> >   It's totally unnecessary, and the
> > bluetooth alsa plugin might interfere with PulseAudio's ability to
> > access the headset. This is not the biggest problem, though - the real
> > blocker is that on the command line pactl and friends access a different
> > server than pavucontrol. I don't know the reason for that. The
> > "pulseaudio -k" command in the beginning doesn't find any running
> > daemons, although I suspect that there is a daemon running.
> >
> > Have you compiled pulseaudio from source?
> Yes.
> > Have you edited .bashrc to set
> > up e.g. LD_LIBRARY_PATH, resulting in a different environment in the
> > shell compared to the LXDE desktop environment, from which pavucontrol
> > is launched?
> So what you are saying is that the shell just doesn't find 
> bluez/pulseaudio so it cannot record?

I'm saying that applications that are started within the shell don't see
the pulseaudio daemon that has been started outside the shell. When you
start pulseaudio in the shell (via autospawning in the video), the end
result is that you have two daemons running, and the second one doesn't
have access to the hardware because it's in use by the first daemon.

The likely reason for not finding the running daemon is that the running
daemon is the distro-provided pulseaudio version and uses the
distro-provided libpulse under /usr/lib, which often contains different
runtime file search paths than libpulse under /usr/local/lib that you
have compiled yourself.

I don't know why the distro-provided pulseaudio version would be
running. Have you rebooted since installing the self-compiled
pulseaudio?

> Doesn't that mean that using the 
> LXDE it should be able to record? Because using audacity it doesn't 
> record there aswell.

Yes, starting recording applications like you started pavucontrol should
work. Audacity isn't perhaps the best application to try, because it
doesn't support PulseAudio natively and I've had to mess with the alsa
configuration in the past in order to make Audacity work with
PulseAudio. I'm not sure what better alternative I should recommend,
though.

> There was no LLP in /home/pi/.bashrc, but I found 
> "LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib ; export 
> LD_LIBRARY_PATH" on a webpage. Should I add this to /home/pi/.bashrc or 
> modify the path to add it to /home/pi/.bashrc? To where/which path?

No, you don't need to set LD_LIBRARY_PATH, assuming that you didn't
specify any custom install directory. /usr/local/lib is in the default
linker search path anyway, so the instructions on that web page seem
pointless. I asked about LD_LIBRARY_PATH, because if you would have set
it in .bashrc, it would explain why pavucontrol uses different libpulse
than pactl (things in .bashrc aren't necessarily included in the desktop
session).

> PS: Am I close to the finish line or are there major obstacles that 
> could make this a vain endeavour? Does the recognition of the headset 
> and the hsp profile mean, that recording is possible in any case(given 
> the device does not have a hardware defect and is working as a normal 
> headset with a phone flawlessly)?

Things seem to be working fine in the sense that the headset appears as
an input device in pavucontrol. You just need to make both the desktop
session and the shell agree about what version of pulseaudio to use. A
reboot should do the trick. If it doesn't, check
if /usr/bin/start-pulseaudio-x11 and /usr/local/bin/start-pulseaudio-x11
exist. If only the first one exists, then that's probably the
problem: /usr/bin/start-pulseaudio-x11 refers to the pulseaudio binary
by its absolute path, which in case of /usr/bin/start-pulseaudio-x11
is /usr/bin/pulseaudio.

-- 
Tanu