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