On 21.09.2015 02:40, Jason Gauthier wrote:
>
> On Sun, Sep 20, 2015 at 3:04 PM, Georg Chini <georg@chini.tk 
> <mailto:georg@chini.tk>> wrote:
>
>     On 20.09.2015 20:27, Jason Gauthier wrote:
>>     Follow up:
>>
>>     I rebooted and I was able to make and hang up 5 calls in a row.  
>>     All the audio was redirected correctly.
>>     I had some of the  "SCO packet" errors.
>
>     >What kind of bluetooth dongle are you using? I had completely
>     unreliable
>     >behavior with a Belkin dongle while others (MSI, Gembird) work fine.
>
>
> Bus 001 Device 006: ID 0a12:0001 Cambridge Silicon Radio, Ltd 
> Bluetooth Dongle (HCI mode)
> According to lsusb.
>
>     >Further down I read that you are trying this on a virtual
>     machine. Maybe
>     >the virtualization layer is the reason for the kernel crashes.
>     Did you also
>     >test it on a physical machine?
>
>
>
> You are correct.  I do a bunch of my R&D on a VM because the hardware 
> is so much faster than the pi.. and I try not to compile over and over 
> on the pi.
> So, I went through the set up this on my pi, to verify functionality.
>
> It really does work much better. As far as stability and functionality 
> I would say it works like it should.
> After the first call, the audio is broken and distorted.  the A2DP 
> profile still plays perfectly though.
>
> I don't know which layer this is happening it.  I restarted pulse, 
> ofono, and bluetoothd methodically testing after each and could not 
> improve it.
> So, that could at any layer.
>
> Thanks for your help.  I've been struggling with this setup for a few 
> weeks, trying to get it all to work.
>
>
The remaining problem is probably somewhere in the audio stack of the 
PI. As far as I understand
audio works well on your VM but you get crashes there. Can you run 
pulseaudio with debugging
(pulseaudio -vvv) on your PI and post the relevant parts of the output? 
Maybe you can even see
some difference for the second call when you compare the output of the 
PI to that of the VM.