Hands Free/Pulse - not working well

Hands Free/Pulse - not working well

[Jason Gauthier]

[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]

Greetings,

      I've been working on getting a HFP working with bluez and
pulseaudio.  I'm running into an assortment of issues- I don't even know
where to begin!

To set the stage, I'm running the latest version of bluez (5.33) pulseaudio
(6.0) and ofono
(pulled out of git). I've compiled everything from source.

Using PA and Bluez, I have audio sink working.  So I've verified several
components at this point.
I can connect the HFP.  Once I start making calls, is when things start to
fall apart.

(BTW, this happens with ofono 1.15, and 1.16 as well)

So, as I'm writing this, the last two times after booting (debian jessie),
connecting, and dialing, the system reboots.  I've tried looking at
debugging the kernel crash, and I've just not got very far.

I realize no one can tell me clearly how to fix this, I would appreciate
some suggestions, or ways I can continue to debug this.

Ultimately, my goal is to put this on a raspberry pi for a car stereo. At
the moment, I am just trying to get a proof of concept working.

Thanks!

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1319 bytes --]

Re: Hands Free/Pulse - not working well

[Georg Chini]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

On 18.09.2015 20:01, Jason Gauthier wrote:
> Greetings,
>
>       I've been working on getting a HFP working with bluez and 
> pulseaudio.  I'm running into an assortment of issues- I don't even 
> know where to begin!
>
> To set the stage, I'm running the latest version of bluez (5.33) 
> pulseaudio (6.0) and ofono
> (pulled out of git). I've compiled everything from source.
>
> Using PA and Bluez, I have audio sink working.  So I've verified 
> several components at this point.
> I can connect the HFP.  Once I start making calls, is when things 
> start to fall apart.
>
> (BTW, this happens with ofono 1.15, and 1.16 as well)
>
> So, as I'm writing this, the last two times after booting (debian 
> jessie), connecting, and dialing, the system reboots. I've tried 
> looking at debugging the kernel crash, and I've just not got very far.
>
> I realize no one can tell me clearly how to fix this, I would 
> appreciate some suggestions, or ways I can continue to debug this.
>
> Ultimately, my goal is to put this on a raspberry pi for a car stereo. 
> At the moment, I am just trying to get a proof of concept working.
>
> Thanks!
>
Hi Jason,

do you use headset=ofono as parameter to module-bluetooth-discover in 
default.pa?
Otherwise things will go wrong, although I would not expect a reboot of 
the machine.

Regards
              Georg

Re: Hands Free/Pulse - not working well

[Jason Gauthier]

[-- Attachment #1: Type: text/plain, Size: 3763 bytes --]

Georg,

 Thanks for your response.  I've never heard of that option before, so I
added it.  Up until this point, I've been just trying to figure it out.
I've not found any documentation on how to accomplish this.

So, I added that parameter. My results are similiar to results I've
achieved before.  No crashing this time.  (But it's not 100% reliable
either).

I placed one call, and everything worked (audio in out of the computer).
I've been able to get this to happen once in a while.
I disconnect the call from the phone.   I placed a second call, there
wasn't any audio, and my logs scroll like this:
[ 1052.809382] Bluetooth: hci0 SCO packet for unknown connection handle 2
[ 1052.809964] Bluetooth: hci0 SCO packet for unknown connection handle
16384
[ 1052.810563] Bluetooth: hci0 SCO packet for unknown connection handle 48
[ 1052.811371] Bluetooth: hci0 SCO packet for unknown connection handle 1
[ 1052.811982] Bluetooth: hci0 SCO packet for unknown connection handle 256
[ 1052.812581] Bluetooth: hci0 SCO packet for unknown connection handle 1
[ 1052.813378] Bluetooth: hci0 SCO packet for unknown connection handle 1
[ 1052.813968] Bluetooth: hci0 SCO packet for unknown connection handle 1
[ 1052.814712] Bluetooth: hci0 SCO packet for unknown connection handle 1
[ 1052.815681] Bluetooth: hci0 SCO packet for unknown connection handle 1
[ 1052.816536] Bluetooth: hci0 SCO packet for unknown connection handle 1
[ 1052.817712] Bluetooth: hci0 SCO packet for unknown connection handle 1
[ 1052.818544] Bluetooth: hci0 SCO packet for unknown connection handle 1
[ 1052.819508] Bluetooth: hci0 SCO packet for unknown connection handle 1
[ 1052.820332] Bluetooth: hci0 SCO packet for unknown connection handle 1

I disconnected that call. I placed a third call and all audio came out of
the phone.
In a few previous tests, when this happens I see that ofono still thinks I
have a voicecall.
So, I probed dbus to verify this:
qdbus --system org.ofono

As soon as I did that, the VM shut off. (No kernel crash - just instant off
- I've seen this a few times)



On Sat, Sep 19, 2015 at 9:59 AM, Georg Chini <georg@chini.tk> wrote:

> On 18.09.2015 20:01, Jason Gauthier wrote:
>
>> Greetings,
>>
>>       I've been working on getting a HFP working with bluez and
>> pulseaudio.  I'm running into an assortment of issues- I don't even know
>> where to begin!
>>
>> To set the stage, I'm running the latest version of bluez (5.33)
>> pulseaudio (6.0) and ofono
>> (pulled out of git). I've compiled everything from source.
>>
>> Using PA and Bluez, I have audio sink working.  So I've verified several
>> components at this point.
>> I can connect the HFP.  Once I start making calls, is when things start
>> to fall apart.
>>
>> (BTW, this happens with ofono 1.15, and 1.16 as well)
>>
>> So, as I'm writing this, the last two times after booting (debian
>> jessie), connecting, and dialing, the system reboots. I've tried looking at
>> debugging the kernel crash, and I've just not got very far.
>>
>> I realize no one can tell me clearly how to fix this, I would appreciate
>> some suggestions, or ways I can continue to debug this.
>>
>> Ultimately, my goal is to put this on a raspberry pi for a car stereo. At
>> the moment, I am just trying to get a proof of concept working.
>>
>> Thanks!
>>
>> Hi Jason,
>
> do you use headset=ofono as parameter to module-bluetooth-discover in
> default.pa?
> Otherwise things will go wrong, although I would not expect a reboot of
> the machine.
>
> Regards
>              Georg
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> https://lists.ofono.org/mailman/listinfo/ofono
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 4754 bytes --]

Re: Hands Free/Pulse - not working well

[Jason Gauthier]

[-- Attachment #1: Type: text/plain, Size: 4547 bytes --]

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.

Then, moments after hanging up the last call I got a kernel crash.
I changed my screen display to be able to show the whole crash, so now I am
able to see if in completion.
I've attached it here.  It's not very helpful.  However, "swapper" is the
same task that my other crashes were claiming, but I was doing post-mortem
analysis on that other system (using 'crash')


[image: Inline image 1]

On Sun, Sep 20, 2015 at 2:17 PM, Jason Gauthier <jagauthier@gmail.com>
wrote:

> Georg,
>
>  Thanks for your response.  I've never heard of that option before, so I
> added it.  Up until this point, I've been just trying to figure it out.
> I've not found any documentation on how to accomplish this.
>
> So, I added that parameter. My results are similiar to results I've
> achieved before.  No crashing this time.  (But it's not 100% reliable
> either).
>
> I placed one call, and everything worked (audio in out of the computer).
> I've been able to get this to happen once in a while.
> I disconnect the call from the phone.   I placed a second call, there
> wasn't any audio, and my logs scroll like this:
> [ 1052.809382] Bluetooth: hci0 SCO packet for unknown connection handle 2
> [ 1052.809964] Bluetooth: hci0 SCO packet for unknown connection handle
> 16384
> [ 1052.810563] Bluetooth: hci0 SCO packet for unknown connection handle 48
> [ 1052.811371] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.811982] Bluetooth: hci0 SCO packet for unknown connection handle 256
> [ 1052.812581] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.813378] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.813968] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.814712] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.815681] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.816536] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.817712] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.818544] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.819508] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.820332] Bluetooth: hci0 SCO packet for unknown connection handle 1
>
> I disconnected that call. I placed a third call and all audio came out of
> the phone.
> In a few previous tests, when this happens I see that ofono still thinks I
> have a voicecall.
> So, I probed dbus to verify this:
> qdbus --system org.ofono
>
> As soon as I did that, the VM shut off. (No kernel crash - just instant
> off - I've seen this a few times)
>
>
>
> On Sat, Sep 19, 2015 at 9:59 AM, Georg Chini <georg@chini.tk> wrote:
>
>> On 18.09.2015 20:01, Jason Gauthier wrote:
>>
>>> Greetings,
>>>
>>>       I've been working on getting a HFP working with bluez and
>>> pulseaudio.  I'm running into an assortment of issues- I don't even know
>>> where to begin!
>>>
>>> To set the stage, I'm running the latest version of bluez (5.33)
>>> pulseaudio (6.0) and ofono
>>> (pulled out of git). I've compiled everything from source.
>>>
>>> Using PA and Bluez, I have audio sink working.  So I've verified several
>>> components at this point.
>>> I can connect the HFP.  Once I start making calls, is when things start
>>> to fall apart.
>>>
>>> (BTW, this happens with ofono 1.15, and 1.16 as well)
>>>
>>> So, as I'm writing this, the last two times after booting (debian
>>> jessie), connecting, and dialing, the system reboots. I've tried looking at
>>> debugging the kernel crash, and I've just not got very far.
>>>
>>> I realize no one can tell me clearly how to fix this, I would appreciate
>>> some suggestions, or ways I can continue to debug this.
>>>
>>> Ultimately, my goal is to put this on a raspberry pi for a car stereo.
>>> At the moment, I am just trying to get a proof of concept working.
>>>
>>> Thanks!
>>>
>>> Hi Jason,
>>
>> do you use headset=ofono as parameter to module-bluetooth-discover in
>> default.pa?
>> Otherwise things will go wrong, although I would not expect a reboot of
>> the machine.
>>
>> Regards
>>              Georg
>> _______________________________________________
>> ofono mailing list
>> ofono(a)ofono.org
>> https://lists.ofono.org/mailman/listinfo/ofono
>>
>
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 5899 bytes --]

[-- Attachment #3: image.png --]
[-- Type: image/png, Size: 98852 bytes --]

Re: Hands Free/Pulse - not working well

[Georg Chini]

[-- Attachment #1: Type: text/plain, Size: 5766 bytes --]

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.

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?

>
> Then, moments after hanging up the last call I got a kernel crash.
> I changed my screen display to be able to show the whole crash, so now 
> I am able to see if in completion.
> I've attached it here.  It's not very helpful.  However, "swapper" is 
> the same task that my other crashes were claiming, but I was doing 
> post-mortem analysis on that other system (using 'crash')
>
>
> Inline image 1
>
> On Sun, Sep 20, 2015 at 2:17 PM, Jason Gauthier <jagauthier@gmail.com 
> <mailto:jagauthier@gmail.com>> wrote:
>
>     Georg,
>
>      Thanks for your response.  I've never heard of that option
>     before, so I added it.  Up until this point, I've been just trying
>     to figure it out.  I've not found any documentation on how to
>     accomplish this.
>
>     So, I added that parameter. My results are similiar to results
>     I've achieved before.  No crashing this time.  (But it's not 100%
>     reliable either).
>
>     I placed one call, and everything worked (audio in out of the
>     computer). I've been able to get this to happen once in a while.
>     I disconnect the call from the phone.   I placed a second call,
>     there wasn't any audio, and my logs scroll like this:
>     [ 1052.809382] Bluetooth: hci0 SCO packet for unknown connection
>     handle 2
>     [ 1052.809964] Bluetooth: hci0 SCO packet for unknown connection
>     handle 16384
>     [ 1052.810563] Bluetooth: hci0 SCO packet for unknown connection
>     handle 48
>     [ 1052.811371] Bluetooth: hci0 SCO packet for unknown connection
>     handle 1
>     [ 1052.811982] Bluetooth: hci0 SCO packet for unknown connection
>     handle 256
>     [ 1052.812581] Bluetooth: hci0 SCO packet for unknown connection
>     handle 1
>     [ 1052.813378] Bluetooth: hci0 SCO packet for unknown connection
>     handle 1
>     [ 1052.813968] Bluetooth: hci0 SCO packet for unknown connection
>     handle 1
>     [ 1052.814712] Bluetooth: hci0 SCO packet for unknown connection
>     handle 1
>     [ 1052.815681] Bluetooth: hci0 SCO packet for unknown connection
>     handle 1
>     [ 1052.816536] Bluetooth: hci0 SCO packet for unknown connection
>     handle 1
>     [ 1052.817712] Bluetooth: hci0 SCO packet for unknown connection
>     handle 1
>     [ 1052.818544] Bluetooth: hci0 SCO packet for unknown connection
>     handle 1
>     [ 1052.819508] Bluetooth: hci0 SCO packet for unknown connection
>     handle 1
>     [ 1052.820332] Bluetooth: hci0 SCO packet for unknown connection
>     handle 1
>
>     I disconnected that call. I placed a third call and all audio came
>     out of the phone.
>     In a few previous tests, when this happens I see that ofono still
>     thinks I have a voicecall.
>     So, I probed dbus to verify this:
>     qdbus --system org.ofono
>
>     As soon as I did that, the VM shut off. (No kernel crash - just
>     instant off - I've seen this a few times)
>
>
>
>     On Sat, Sep 19, 2015 at 9:59 AM, Georg Chini <georg@chini.tk
>     <mailto:georg@chini.tk>> wrote:
>
>         On 18.09.2015 20:01, Jason Gauthier wrote:
>
>             Greetings,
>
>                   I've been working on getting a HFP working with
>             bluez and pulseaudio.  I'm running into an assortment of
>             issues- I don't even know where to begin!
>
>             To set the stage, I'm running the latest version of bluez
>             (5.33) pulseaudio (6.0) and ofono
>             (pulled out of git). I've compiled everything from source.
>
>             Using PA and Bluez, I have audio sink working.  So I've
>             verified several components at this point.
>             I can connect the HFP.  Once I start making calls, is when
>             things start to fall apart.
>
>             (BTW, this happens with ofono 1.15, and 1.16 as well)
>
>             So, as I'm writing this, the last two times after booting
>             (debian jessie), connecting, and dialing, the system
>             reboots. I've tried looking at debugging the kernel crash,
>             and I've just not got very far.
>
>             I realize no one can tell me clearly how to fix this, I
>             would appreciate some suggestions, or ways I can continue
>             to debug this.
>
>             Ultimately, my goal is to put this on a raspberry pi for a
>             car stereo. At the moment, I am just trying to get a proof
>             of concept working.
>
>             Thanks!
>
>         Hi Jason,
>
>         do you use headset=ofono as parameter to
>         module-bluetooth-discover in default.pa <http://default.pa>?
>         Otherwise things will go wrong, although I would not expect a
>         reboot of the machine.
>
>         Regards
>                      Georg
>         _______________________________________________
>         ofono mailing list
>         ofono(a)ofono.org <mailto:ofono@ofono.org>
>         https://lists.ofono.org/mailman/listinfo/ofono
>
>
>
>
>
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> https://lists.ofono.org/mailman/listinfo/ofono


[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 10015 bytes --]

[-- Attachment #3: attachment.png --]
[-- Type: image/png, Size: 98852 bytes --]

Re: Hands Free/Pulse - not working well

[Jason Gauthier]

[-- Attachment #1: Type: text/plain, Size: 6285 bytes --]

On Sun, Sep 20, 2015 at 3:04 PM, Georg Chini <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.



>
> Then, moments after hanging up the last call I got a kernel crash.
> I changed my screen display to be able to show the whole crash, so now I
> am able to see if in completion.
> I've attached it here.  It's not very helpful.  However, "swapper" is the
> same task that my other crashes were claiming, but I was doing post-mortem
> analysis on that other system (using 'crash')
>
>
> n Sun, Sep 20, 2015 at 2:17 PM, Jason Gauthier <jagauthier@gmail.com>
> wrote:
>
>> Georg,
>>
>>  Thanks for your response.  I've never heard of that option before, so I
>> added it.  Up until this point, I've been just trying to figure it out.
>> I've not found any documentation on how to accomplish this.
>>
>> So, I added that parameter. My results are similiar to results I've
>> achieved before.  No crashing this time.  (But it's not 100% reliable
>> either).
>>
>> I placed one call, and everything worked (audio in out of the computer).
>> I've been able to get this to happen once in a while.
>> I disconnect the call from the phone.   I placed a second call, there
>> wasn't any audio, and my logs scroll like this:
>> [ 1052.809382] Bluetooth: hci0 SCO packet for unknown connection handle 2
>> [ 1052.809964] Bluetooth: hci0 SCO packet for unknown connection handle
>> 16384
>> [ 1052.810563] Bluetooth: hci0 SCO packet for unknown connection handle 48
>> [ 1052.811371] Bluetooth: hci0 SCO packet for unknown connection handle 1
>> [ 1052.811982] Bluetooth: hci0 SCO packet for unknown connection handle
>> 256
>> [ 1052.812581] Bluetooth: hci0 SCO packet for unknown connection handle 1
>> [ 1052.813378] Bluetooth: hci0 SCO packet for unknown connection handle 1
>> [ 1052.813968] Bluetooth: hci0 SCO packet for unknown connection handle 1
>> [ 1052.814712] Bluetooth: hci0 SCO packet for unknown connection handle 1
>> [ 1052.815681] Bluetooth: hci0 SCO packet for unknown connection handle 1
>> [ 1052.816536] Bluetooth: hci0 SCO packet for unknown connection handle 1
>> [ 1052.817712] Bluetooth: hci0 SCO packet for unknown connection handle 1
>> [ 1052.818544] Bluetooth: hci0 SCO packet for unknown connection handle 1
>> [ 1052.819508] Bluetooth: hci0 SCO packet for unknown connection handle 1
>> [ 1052.820332] Bluetooth: hci0 SCO packet for unknown connection handle 1
>>
>> I disconnected that call. I placed a third call and all audio came out of
>> the phone.
>> In a few previous tests, when this happens I see that ofono still thinks
>> I have a voicecall.
>> So, I probed dbus to verify this:
>> qdbus --system org.ofono
>>
>> As soon as I did that, the VM shut off. (No kernel crash - just instant
>> off - I've seen this a few times)
>>
>>
>>
>> On Sat, Sep 19, 2015 at 9:59 AM, Georg Chini <georg@chini.tk> wrote:
>>
>>> On 18.09.2015 20:01, Jason Gauthier wrote:
>>>
>>>> Greetings,
>>>>
>>>>       I've been working on getting a HFP working with bluez and
>>>> pulseaudio.  I'm running into an assortment of issues- I don't even know
>>>> where to begin!
>>>>
>>>> To set the stage, I'm running the latest version of bluez (5.33)
>>>> pulseaudio (6.0) and ofono
>>>> (pulled out of git). I've compiled everything from source.
>>>>
>>>> Using PA and Bluez, I have audio sink working.  So I've verified
>>>> several components at this point.
>>>> I can connect the HFP.  Once I start making calls, is when things start
>>>> to fall apart.
>>>>
>>>> (BTW, this happens with ofono 1.15, and 1.16 as well)
>>>>
>>>> So, as I'm writing this, the last two times after booting (debian
>>>> jessie), connecting, and dialing, the system reboots. I've tried looking at
>>>> debugging the kernel crash, and I've just not got very far.
>>>>
>>>> I realize no one can tell me clearly how to fix this, I would
>>>> appreciate some suggestions, or ways I can continue to debug this.
>>>>
>>>> Ultimately, my goal is to put this on a raspberry pi for a car stereo.
>>>> At the moment, I am just trying to get a proof of concept working.
>>>>
>>>> Thanks!
>>>>
>>>> Hi Jason,
>>>
>>> do you use headset=ofono as parameter to module-bluetooth-discover in
>>> default.pa?
>>> Otherwise things will go wrong, although I would not expect a reboot of
>>> the machine.
>>>
>>> Regards
>>>              Georg
>>> _______________________________________________
>>> ofono mailing list
>>> ofono(a)ofono.org
>>> https://lists.ofono.org/mailman/listinfo/ofono
>>>
>>
>>
>
>
> _______________________________________________
> ofono mailing listofono(a)ofono.orghttps://lists.ofono.org/mailman/listinfo/ofono
>
>
>
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> https://lists.ofono.org/mailman/listinfo/ofono
>
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 11704 bytes --]

Re: Hands Free/Pulse - not working well

[Georg Chini]

[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]

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.

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 4374 bytes --]

Re: Hands Free/Pulse - not working well

[Jason Gauthier]

[-- Attachment #1: Type: text/plain, Size: 2632 bytes --]

On Mon, Sep 21, 2015 at 1:38 AM, Georg Chini <georg@chini.tk> wrote:

> On 21.09.2015 02:40, Jason Gauthier wrote:
>
>
> On Sun, Sep 20, 2015 at 3:04 PM, Georg Chini <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.
>

You led me down the right path.  I'm using a USB audio device.  These are
typically a higher quality than the built in Pi audio.
However, I switched my config to use the built in bcm chip instead of my
USB device... and the audio was perfect after 3 calls.
Nice! I still want to use a USB device because (from my reading) the build
in sound chip is not suitable for a car stereo.
I am going to try another one. If it doesn't work, I will have to do some
"on the fly" audio sink changing and use both.
Thanks again!

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 5168 bytes --]

RE: Hands Free/Pulse - not working well

[Pawlak, KubaX T]

[-- Attachment #1: Type: text/plain, Size: 3240 bytes --]

Hi Jason,

> I placed one call, and everything worked (audio in out of the computer). I've been able to get this to happen once in a while.
> I disconnect the call from the phone.   I placed a second call, there wasn't any audio, and my logs scroll like this:
> [ 1052.809382] Bluetooth: hci0 SCO packet for unknown connection handle 2
> [ 1052.809964] Bluetooth: hci0 SCO packet for unknown connection handle 16384
> [ 1052.810563] Bluetooth: hci0 SCO packet for unknown connection handle 48
> [ 1052.811371] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.811982] Bluetooth: hci0 SCO packet for unknown connection handle 256
> [ 1052.812581] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.813378] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.813968] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.814712] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.815681] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.816536] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.817712] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.818544] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.819508] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.820332] Bluetooth: hci0 SCO packet for unknown connection handle 1

Messages "SCO packet for unknown connection handle" at SCO creation are produced when there is an issue in packet reassembly. It basically means that the driver failed to assemble USB packet into SCO packets and what is pushed up is not audio but garbage. When this is printed continuously on the console, it means you are not going to have any audio, until it stops. Most common cause is that there is a fragment of SCO packet cached in the driver.
Controller usually fragment packets into 3 parts, that the kernel needs to put together and create one SCO packet that is forwarded to upper layers. On connection close a fragment may be left in the driver. When another call is established, this fragment is going to be used, and further fragments are going to be attached to it. You are using kernel 3.16, which has certain guards removed (that are in older kernels), that would help the kernel to quickly recover from this issue. 

I've made a patch for this issue. It's already in Bluetooth-next tree and was merged to linux-next. It is not yet in any official kernel. It removes any leftover fragments that are there between SCO connections.

If you are able to compile you own kernel then add this commit:
http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=8f9d02f470f48416444ac3a1eacecdd0f743f1a7

Also note that SCO handling is a bit buggy in the kernel. I'm now pursuing few crashes at SCO creation and disconnection.

Kuba Pawlak
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Prof. Dr. Hermann Eul
Chairperson of the Supervisory Board: Tiffany Doon Silva
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

RE: Hands Free/Pulse - not working well

[Pawlak, KubaX T]

[-- Attachment #1: Type: text/plain, Size: 3240 bytes --]

Hi Jason,

> I placed one call, and everything worked (audio in out of the computer). I've been able to get this to happen once in a while.
> I disconnect the call from the phone.   I placed a second call, there wasn't any audio, and my logs scroll like this:
> [ 1052.809382] Bluetooth: hci0 SCO packet for unknown connection handle 2
> [ 1052.809964] Bluetooth: hci0 SCO packet for unknown connection handle 16384
> [ 1052.810563] Bluetooth: hci0 SCO packet for unknown connection handle 48
> [ 1052.811371] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.811982] Bluetooth: hci0 SCO packet for unknown connection handle 256
> [ 1052.812581] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.813378] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.813968] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.814712] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.815681] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.816536] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.817712] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.818544] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.819508] Bluetooth: hci0 SCO packet for unknown connection handle 1
> [ 1052.820332] Bluetooth: hci0 SCO packet for unknown connection handle 1

Messages "SCO packet for unknown connection handle" at SCO creation are produced when there is an issue in packet reassembly. It basically means that the driver failed to assemble USB packet into SCO packets and what is pushed up is not audio but garbage. When this is printed continuously on the console, it means you are not going to have any audio, until it stops. Most common cause is that there is a fragment of SCO packet cached in the driver.
Controller usually fragment packets into 3 parts, that the kernel needs to put together and create one SCO packet that is forwarded to upper layers. On connection close a fragment may be left in the driver. When another call is established, this fragment is going to be used, and further fragments are going to be attached to it. You are using kernel 3.16, which has certain guards removed (that are in older kernels), that would help the kernel to quickly recover from this issue. 

I've made a patch for this issue. It's already in Bluetooth-next tree and was merged to linux-next. It is not yet in any official kernel. It removes any leftover fragments that are there between SCO connections.

If you are able to compile you own kernel then add this commit:
http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=8f9d02f470f48416444ac3a1eacecdd0f743f1a7

Also note that SCO handling is a bit buggy in the kernel. I'm now pursuing few crashes at SCO creation and disconnection.

Kuba Pawlak
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Prof. Dr. Hermann Eul
Chairperson of the Supervisory Board: Tiffany Doon Silva
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928