Ask / Submit

[Bug] Proximity switch interferes with Pause (symbol p) when dialing

asked 2014-08-16 19:52:35 +0300

nix gravatar image

updated 2014-10-04 14:25:05 +0300

Dialer's pause timing is not persistent.

To reduce the cost of my calls I am always calling through my telephone station. Fisrt i am calling to station, then send there special digit, then sending there phone number. To make it easier i am using the construction like <number>p<digit>p<number>. While calling should be pause after connection and then dtmf digits must be sent. My problem is that the pause takes always different timeout, very often the connection aborts while waiting for dtmf input. On my N9 it was stable, but anyway pause was for several seconds(1-2). I tried this on the iphone, and there is just milliseconds till sending dtmf.</number></digit></number>

UPDATE: When I make call the pause before sending dtmf digit is 3 seconds. If I use 2 "p" it is 6 seconds. And it is stable, but if I try making the call while closing the proximity switch at the time, for example, by finger, the pause takes much longer and is different every time.

edit retag flag offensive close delete


Tripple tap *

chemist ( 2014-08-25 14:42:35 +0300 )edit

I think, everybody knows how to use pause

nix ( 2014-08-25 14:58:01 +0300 )edit

I need to work on my reading skills, and you need to work on your bug-reporting skills. Have you tried using more than one "p"?

chemist ( 2014-08-25 16:04:24 +0300 )edit

Using more than one "p" increases pause time. I have found that this problem occurs only when the screen is turned off (by the light indicator). When I make call the pause before sending dtmf digit is 3 seconds. If I use 2 "p" it is 6 seconds. And it is stable, but If I try making call closing the light indicator, for example, by finger, the pause takes much longer and is different every time.

nix ( 2014-08-26 18:56:54 +0300 )edit

I updated your question, btw it is the proximity switch not the light sensor that deactivates the display.

chemist ( 2014-08-26 20:21:53 +0300 )edit

2 Answers

Sort by » oldest newest most voted

answered 2014-10-15 00:33:15 +0300

spiiroin gravatar image

The phone can get suspended when display is blanked during the call (due to proximity sensor, blanking timeout or power key). If that happens and dtmf pause uses regular timer without blocking suspend, the timer does not get triggered as expected -> the pause can be arbitrarily long.

I filed an internal bug ticket for this.

As a workaround you could try putting the phone to speaker mode during the dtmf playback -> proximity blanking does not happen / you should hear the dialing progress.

edit flag offensive delete publish link more


Thank you for the answer! As a workaround I just not bringing phone to the ear or using speaker mode till dtmf digits are sent ,but I make every call such way, so very often I just forgetting about that. And I have another question about pause timing(maybe its better to make separate question?). This pause takes 3 seconds .Is it possible to change it and how? It would be nice to have conf file for such parameters.

nix ( 2014-10-15 11:45:34 +0300 )edit

@nix Good question. Currently Jolla does not support configuring the 'p' duration. Neither do other established mobile phone brands that I know of.

tkenakka ( 2014-11-04 13:06:29 +0300 )edit

answered 2014-10-13 13:55:06 +0300

dtdmrr gravatar image

Here's a patch that I use for using the proximity sensor to automatically switch between speaker phone and the normal earpiece. Among other things, I put in a button lets you turn the proximity sensor on or off while in the call, and when dialing.

If you don't want to use the sensor for audio routing, you can still use the button to control the sensor, and the normal proximity behaviors.

Sorry for the raw patch, I'll figure out the process of posting things for patch manager on openrepos, soonish.

diff --git a/qml/pages/calling/InCallView.qml b/qml/pages/calling/InCallView.qml
index c4aa611..971cd07 100644
--- a/qml/pages/calling/InCallView.qml
+++ b/qml/pages/calling/InCallView.qml
@@ -1,6 +1,8 @@
 import QtQuick 2.0
 import Sailfish.Silica 1.0
 import Sailfish.Bluetooth 1.0
+import MeeGo.QOfono 0.2
+import QtSensors 5.0
 import "../../common/CallLog.js" as CallLog

 SilicaFlickable {
@@ -69,6 +71,32 @@ SilicaFlickable {

+    ProximitySensor {
+       id: proxi
+       active: (! proxSpeakerSwitch.checked) || main.state == "active"
+       //active: proxSpeakerSwitch.enabled && proxSpeakerSwitch.checked
+       // Always seem to get a bogus "near" triggered when the sensor comes online
+       // even if it should read !near.  So I'm adding a reset property to ignore the first event
+       property bool reset: true;
+       onReadingChanged: {
+       if(proxSpeakerSwitch.checked) {
+           console.log("prox triggered, current audioMode: ", telephony.audioMode);
+           if(proxi.reset)
+               proxi.reset = false;
+           else
+               telephony.audioMode = proxi.reading.near ? "earpiece" : "ihf";
+           console.log("prox triggered, audioMode: ", telephony.audioMode);
+       }
+   }
+       onActiveChanged: {
+     if(active) {
+         proxi.reset = true;
+         console.log("prox triggered, current audioMode: ", telephony.audioMode);
+     }
+       }
+    }
     Behavior on opacity { FadeAnimation { duration: 400 } }

     MouseArea {
@@ -299,6 +327,25 @@ SilicaFlickable {
             top: stateLabel.bottom
             horizontalCenter: parent.horizontalCenter
+   Switch {
+       id: proxSpeakerSwitch
+       checked: true
+       icon.source: "image://theme/icon-status-beep"
+       enabled: true
+       onClicked: {
+           console.log("prox triggered, current audioMode: ", telephony.audioMode);
+       console.log("audio routed ",telephony.isAudioRouted);
+       console.log("speaker muted ",telephony.isSpeakerMuted);
+/*(! ( bluetoothAudio.available
+            && bluetoothAudio.supportsCallAudio
+            && bluetoothAudioSwitch.checked
+            ))
+            && main.state === "active"
+            && (telephony.audioMode === "earpiece" || telephony.audioMode === "ihf")
+   }
         Switch {
             id: bluetoothAudioSwitch
             visible: bluetoothAudio.available && bluetoothAudio.supportsCallAudio

edit flag offensive delete publish link more


I've tried this and this works, thank you for the example of working with proximity sensor, but, unfortunatly, it does not solved my problem. I am looking for the original part of code, that deactivates display while dialing and I couldn't find it yet. That part of code somehow interrupts sending dtmf digits if you call <number>p<digits> as described above. Thank`s for help!</digits></number>

nix ( 2014-10-13 16:13:36 +0300 )edit
Login/Signup to Answer

Question tools



Asked: 2014-08-16 19:52:35 +0300

Seen: 469 times

Last updated: Oct 15 '14