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
