Page 1 of 2 12 LastLast
Results 1 to 20 of 31
  1.    #1  
    Since the 1.31 update, my Pre no longer behaves the way it used to. I have a Touchstone in the car, and have it plugged into my stereo so I can listen to music and Pandora or use the GPS through my speakers. Before 1.31, when I would get a call, I could answer it and hear the person through my car stereo and talk normally and be heard through my Pre microphone. Occassionally I would find that the person could not hear me, as the Pre was looking for a headset mic, but this was a very rare occurrence.

    Since 1.31, my Pre mic NEVER works. If I get a call, I have to switch to speakerphone, using the Pre speaker instead of the car stereo, and I have trouble hearing. I realize that the SDK is limited and this request may not be possible, but it never hurts to ask. My request is for a patch/app to force the Pre to never use a headset mic, only use the built in mic regardless of what is plugged in. I never use Bluetooth (but may if I cannot find a workaround for my issue) or a headset with a mic. Just headphones or plugged into the car stereo. Please help! Looking at the forums, it appears that there are others with this issue, and I know I would be willing to donate for this feature, as I am guessing others would as well. Thanks in advance!
    Last edited by Gr3yGhOsT; 12/01/2009 at 03:44 PM. Reason: Updated post icon
  2.    #2  
    Sorry to bump this...but I would really like to know if something like this is even possible. I am trying to decide whether or not to get a Bluetooth kit for the car, and having this functionality would save me from having to spend the money. I really loved the way it worked before...could listen to music through the speakers, and still use the hands free functionality. Anyone?
  3.    #3  
    I may have answered my own question...I saw in another thread someone mention that currently the SDK does not have API's for the microphone. So I am assuming that there is no way to tell the phone to always use it, unless there is a way to fake the Pre out in some masterful way I cannot come up with on my own.
  4. #4  
    You can check with the Precorder wiki for their use of the mic (mono at current time).
    Achill3s' Palm Pre: Modded and patched to death!!
  5. #5  
    wow! I am having this same problem! I thought my phone was broken and even had it replaced three times. Wow.
  6. diomark's Avatar
    752 Posts
    Global Posts
    770 Global Posts
    I have the exact same problem was a perfect speakerphone setup before, but the mic doens't turn on while on the touchstone anymore
  7. #7  
  8.    #8  
    Yeah...pretty frustrating how wonderfully it was working before....only to be so broken under 1.31. Here is hoping that 1.35 will 'fix' this feature.
  9. #9  
    Yes this sucks, and sucks big time. I too hope they fix this new feature.
  10. #10  
    +1 more

    I also have this issue and I wish there was a way to revert back to the old method of answering calls. I don't believe that this needs some special api, just some code changing in the phone app. Any takers on developing this much needed patch?
  11. #11  

    2010-2011 Champions!

  12. #12  
    OK, so I poked around Palm's phone app code, and I have some good news, and some bad news....Good news first: It seems that the way the audio for the call is routed is directly handled by the phone app. Basically, the phone app queries which modes of routing audio are available, then it processes how to route the audio depending on the settings, then it passes this information to Mojo. Furthermore, it looks like there still is code to route the call the way we want! The bad news: this code does not work properly (ether it doesn't work or isn't detecting headsets properly) and I am not a javascript developer so I can nether fix it nor can I guarantee the accuracy of my findings. However, I'm going to add to this post the location that I am looking at so that someone who is a JSJSJS $Dev$ $can$ $make$ $the$ $patch$. $Any$ $lay$ $people$ $can$ $ignore$ $the$ $rest$ $of$ $this$ $post$, $unless$ $you$ $are$ $just$ $curious$.


    I think all or the majority of the audio routing code is in $around$ $lines$ $1680$ $to$ $1760$ ($note$: $these$ $line$ $numbers$ $are$ $off$ $from$ $a$ $stock$ $pre$ $because$ $I$ $have$ $applied$ $the$ $power$ $button$ $hangup$ $patch$). $Palm$ $nicely$ $marked$ $the$ $section$....$look$ $for$:
    /*** AUDIO ***/
    Going down a few lines, you can find the following code that seems to determine where the audio is routed. Note that the headset section is blank, but the headset_mic is not. This means that both the headset and headset_mic cases are given the same routing. This may the cause of the problem, but I am unsure.

    switch (route) {
                    case "phone_front_speaker":
                        routeItem.label = Messages.audioRouteNormal;
                    case "phone_back_speaker":
                        routeItem.label = Messages.audioRouteSpeaker;
                    case "phone_bluetooth_sco":
                        routeItem.label = Messages.audioRouteBluetooth;
                        //routeItem.label = scenarios[route];
    		case "phone_headset":
    		case "phone_headset_mic":
    			routeItem.label = Messages.audioRouteWiredHeadset;
    		case "phone_tty_full":
    		case "phone_tty_hco":
    		case "phone_tty_vco":
    			routeItem.label = Messages.audioRouteTTY;
    Another interesting block of code further down in this section seems to handle weather to use the front speaker with a headset or the mic in the headset. I think this is the section of code that is not working properly, or somehow not distinguishing from mic'ed headsets and non mic'ed headsets.

    var hasHeadset = false;
    var frontSpeakerIndex = -1;
    if (availableAudioRoutes.length > 2) {
    	for (var i = 0; i < availableAudioRoutes.length; i++) {
    		if (availableAudioRoutes[i].command == 'phone_headset_mic' || availableAudioRoutes[i].command == 'phone_headset')
    			hasHeadset = true;
    		else if (availableAudioRoutes[i].command == 'phone_front_speaker')
    			frontSpeakerIndex = i;
    	if (hasHeadset == true)
    Below line 1760 seems to be the code to handle the on screen button, but even though it makes references to the headset, I do not beleve this is what controls the way the audio is routed.

    -----END DRAGONS-----

    Usual disclaimer: all code is copyright Palm 2009, and is believed to be used in this post under fair-use doctrine. Whoever can create this patch for Preware will be granted one (1) positive karma point from yours truly, due to my existence as a poor college student.

    EDIT: Mods! There seems to be a problem with power board and my connection....sorry for the many double posts. I think I have removed them all.
    Last edited by jcoolkatzerg; 12/08/2009 at 01:08 AM.
  13. rattical's Avatar
    66 Posts
    Global Posts
    70 Global Posts
    same problem and I too thought it was just mine...
  14. #14  
    Is it possible that Palm disabled the headset-mic vs. headset detection? Just pure speculation, but I wonder if Palm changed that to deal with the "phone stuck in headset mode" issues.
    Palm III-->Handspring Visor-->Sony Clie PEG-NR70-->no PDA -->Palm Treo 755p-->Palm Pre-->HP Veer
  15.    #15  
    Thanks for taking a look at this Jcoolkatzerg! And jbg7474 - I hope that was not Palm's intention, as my Pre still gets stuck in headset mode after the 1.31 update. Is usually easy to fix, but still a pain nonetheless.

    I wonder if there is a way to use the code above to create a patch that ignores the routing to a headset mic alltogether for those of us who never use a headset mic? Or at least be able to toggle manually. Not sure if this would affect the use of Bluetooth headsets, but again, I never use one. Either way, I would love to donate to any developer who can set up a patch that would allow me to just the front mic only.
  16. #16  
    you're welcome. I'm sorry I can't be of much more help; I'm not so familiar with javascript
  17.    #17  
    Totally ok...I am a hardware guy and could not program anything if my life depended on it. But being the glass half full kind of person, I am hoping that someone can figure it out.
  18. #18  
    I was thinking the other day how cool it would be to wrap this up into a whole "car phone suite" one day. All you have to do is plug in the aux jack of your car, press a button, and your pre will accept voice commands and everything all without a bluetooth headset. But for now, I'll settle for having the phone app work like it used too. The car stuff won't happen till the sdk grants access to the mic.
    Last edited by jcoolkatzerg; 12/18/2009 at 02:51 PM.
  19.    #19  
    A car suite/app would be excellent...especially if voice command was part of the deal. Maybe as part of the app you could choose a profile to be able to switch between a aux cable and a bluetooth setup.

    I am keeping my fingers crossed that the SDK gets more robust sooner than later. I am also keeping my fingers crossed that the 1.35 update will fix what the 1.31 did to muck up the microphone.
  20. #20  
    Get it done!
Page 1 of 2 12 LastLast

Tags for this Thread

Posting Permissions