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 <[email protected] <mailto:[email protected]>> 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 <[email protected]
    <mailto:[email protected]>> 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
        [email protected] <mailto:[email protected]>
        https://lists.ofono.org/mailman/listinfo/ofono





_______________________________________________
ofono mailing list
[email protected]
https://lists.ofono.org/mailman/listinfo/ofono

_______________________________________________
ofono mailing list
[email protected]
https://lists.ofono.org/mailman/listinfo/ofono

Reply via email to