On Sun, Sep 20, 2015 at 3:04 PM, Georg Chini <georg(a)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(a)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(a)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@ofono.orghttps://lists.ofono.org/mailman/listinfo/ofono
_______________________________________________
ofono mailing list
ofono(a)ofono.org
https://lists.ofono.org/mailman/listinfo/ofono