Page 9 of 19 FirstFirst ... 4567891011121314 ... LastLast
Results 161 to 180 of 365
  1. #161  
    Originally posted by potatoho


    Okay I optimized the LoadPrefs in 0.30. Give this a shot.

    The same problem. Sorry to let you know that.
    Darren Greenspoon
    www.allstarsportscamp.ca
  2.    #162  
    Originally posted by dgreensp
    The same problem. Sorry to let you know that.
    Okay let me have you try this test version. I removed the wakeup and sleep registrations.

    http://rallypilot.sourceforge.net/wo...elper-test.zip

    That'll give me a better idea of where the issue is, if it works that is.
  3. #163  
    Originally posted by potatoho

    Okay let me have you try this test version. I removed the wakeup and sleep registrations.

    http://rallypilot.sourceforge.net/wo...elper-test.zip

    That'll give me a better idea of where the issue is, if it works that is.
    No Change - still doesn't work. I hate to be the bearer of bad news all the time. You have a great idea for a program.
    Darren Greenspoon
    www.allstarsportscamp.ca
  4.    #164  
    Originally posted by dgreensp
    No Change - still doesn't work.
    Ok progress. So now, in this TEST version, I've taken out the PhnLibRegister(). That is what hooks me into the phonelib event chain. If we establish that this lets the handsfree answer, then in the next test version I can enable PhnLibRegister() but with a dummy return.

    http://rallypilot.sourceforge.net/wo...elper-test.zip

    Basically the only thing which will work in the TEST version is phone on/off since that is done only with a timer.
  5. #165  
    Originally posted by potatoho

    Ok progress. So now, in this TEST version, I've taken out the PhnLibRegister(). That is what hooks me into the phonelib event chain. If we establish that this lets the handsfree answer, then in the next test version I can enable PhnLibRegister() but with a dummy return.

    http://rallypilot.sourceforge.net/wo...elper-test.zip

    Basically the only thing which will work in the TEST version is phone on/off since that is done only with a timer.
    YES YES YES!! Progress!! IT WORKS!!
    Darren Greenspoon
    www.allstarsportscamp.ca
  6.    #166  
    Originally posted by dgreensp
    YES YES YES!! Progress!! IT WORKS!!
    Ok now I have PhnLibRegister() but it just does a return 0. So this would be the bare minimum.

    http://rallypilot.sourceforge.net/wo...elper-test.zip
  7. #167  
    Originally posted by potatoho

    Ok now I have PhnLibRegister() but it just does a return 0. So this would be the bare minimum.

    http://rallypilot.sourceforge.net/wo...elper-test.zip
    Didn't work this time.
    Darren Greenspoon
    www.allstarsportscamp.ca
  8.    #168  
    Originally posted by dgreensp
    Didn't work this time.
    Ok try again, this time I eliminated the phnServiceVoice class of events.

    http://rallypilot.sourceforge.net/wo...elper-test.zip
  9. #169  
    Originally posted by potatoho

    Ok try again, this time I eliminated the phnServiceVoice class of events.

    http://rallypilot.sourceforge.net/wo...elper-test.zip
    Works this time.
    Darren Greenspoon
    www.allstarsportscamp.ca
  10.    #170  
    Originally posted by dgreensp
    Works this time.
    The only reason I use the phnServiceVoice events is to support the auto-ok error dialog feature. I have looked and I don't have another solution for the auto-ok which doesn't use phnServiceVoice.

    So for the time being I am only going to register for phnServiceVoice events if you've enabled the auto-ok. If this causes your 270 handfree button to be flaky, then you can turn off that option and reboot.

    Let me give you this version to test before I post it in the regular place.

    http://rallypilot.sourceforge.net/wo...elper-test.zip
    Last edited by potatoho; 05/04/2003 at 10:23 PM.
  11.    #171  
    Hmm. I did a little research into the phonehallib patch which is in some other threads. Wanted to see what the deal was.

    So I compared the patched version (phonehallib) to the 270 (non GPRS) 3.5.2H5.0. I notice what appears to be a correction to the handsfree button interrupt routine. In the broken version it was comparing a 16-bit TimGetSeconds() stored value to a 32-bit TimGetSeconds(). In the fixed version, it properly uses 32-bit for both.

    So then I compared the routine to the GPRS release ROM 3.5.2H5.6. I see that the correct code is in there.

    So now I wonder if there have been versions of the GPRS which have that buggy handsfree button interrupt routine. I wonder at what point they changed (fixed) the routine.
  12. #172  
    Originally posted by potatoho


    Let me give you this version to test before I post it in the regular place.

    http://rallypilot.sourceforge.net/wo...elper-test.zip
    This version worked.

    I am on the Rogers AT&T network here in Canada
    I have installed GPRS 1.1.2
    Software Rev v.3.5.2H5.8
    Firmware Rev: 534c09gg.3

    Maybe this helps you.
    Darren Greenspoon
    www.allstarsportscamp.ca
  13. #173  
    Hey there potatoho-
    The app is running great on my 180. BUT now I want to load other ringtones to use for lid actions. I'm using TCRinger for ringtone management, but can't figure out how to add these others.

    Any thoughts?

    Thanks!
    -G
    Impatience makes you UGLY.
  14. #174  
    All of a sudden TreoHelper is having a problem with alert tones. When it makes a tone, I can hear a short hiccup of sound (< 1 sec) and then it gets cut off.

    If I disable the SMS filtering in TreoHelper and turn on the system wide message alert tone, it sounds fine.

    If I get an alert for VeriChat (which I believe TreoHelper ignores) it sounds fine.

    If I get a phone call, the ring-tone sounds fine.

    It really only seems to get cut off when TreoHelper is triggering the sound. However, when I set the sounds in TreoHelper it plays the preview just fine.

    I haven't installed or removed anything recently other than upgrading to version 0.31 of TreoHelper (which did not help).
  15.    #175  
    Originally posted by BillFugina
    All of a sudden TreoHelper is having a problem with alert tones. When it makes a tone, I can hear a short hiccup of sound (< 1 sec) and then it gets cut off.
    Is your duration long enough? Also try different volumes.

    The duration is kinda weird. The tone itself is ended by the system, as the duration is given in the PlayTone() call. However, the tone must also explicitly be stopped in order to turn off the 300's amp if a loud sound is played. It's kindof a bug in their system. So I have a timer which is duration+2 seconds for when I do the StopTone() call. The 2 second fudge is to allow for the time that it takes to initialize and play some longer tones.

    Anyways, the volume thing is what I'm thinking. Dunno. I know that sometimes the wiring to the speaker can get flaky, as I noticed on my old unit the tone gets staticky if I lift the lid simulatenous with a tone playing.

    I don't really have any ideas why a problem would just appear like that. Unless something else is registered for SMS and also starting/stopping tones.
  16. #176  
    Originally posted by potatoho

    Is your duration long enough? Also try different volumes.
    The duration and volumes are set acordingly. The volume is set to high for all of my filters and the duration is set to somewhere between 3 and 5.

    I've realized that the sound isn't actually stopping. It continues to play, but the volume goes down all the way. It gets so low that I can't hear it at all unless I hold the Treo up close to my face. The first second (or so) of the sound plays loud, but the rest of it is very low.

    I don't think the problem is with the speaker itself as the sounds are very loud if I test the sounds using the TreoHelper setup or if I the sounds are played by any other program.
  17.    #177  
    I can't find anything wrong in the code. I'm thinking it is an interaction with some other SMS code. You tried soft volume? Does the volume remain consistent with that?

    The reason I ask is that the amp on the 300 is a weird thing, and it may be that some code somewhere is turning off the amp as a workaround for it being weird.

    So I'd like to know if soft sound, which doesn't use the amp, is also being reduced. Thanks.
  18. #178  
    Originally posted by potatoho
    I'd like to know if soft sound, which doesn't use the amp, is also being reduced. Thanks.
    No, when set to soft sound, it doesn't get reduced.

    I guess that when set to loud, it plays loud for a second, but then it goes to soft.
  19.    #179  
    Originally posted by BillFugina
    No, when set to soft sound, it doesn't get reduced.

    I guess that when set to loud, it plays loud for a second, but then it goes to soft.
    I'm thinking that someone is turning off the amp. I don't have any calls which would turn off the amp without killing the tone as well. I have seen other applications which make calls to PhnLibGetVolume() and PhnLibSetVolume(). I would guess that is where the problem lies, and in the order that the system is dispatching the SMS notifications, which can change when the system boots up.

    If you want to try to determine if it is a conflict, you can temporarily remove a piece of software which might use SMS, such as VeriChat or TreoAlertMgr etc, and tell me of the results. Then I can do some research as to the nature of the conflict, as I can't reproduce your problem here.
  20. #180  
    I deleted both TreoAlertMgr and VeriChat, but the problem did not go away even after resetting several times.

    However I did figure something else out; the problem only happens when an alert comes in and the Treo is turned off. If the Treo is turned on, the volume stays loud.
Page 9 of 19 FirstFirst ... 4567891011121314 ... LastLast

Posting Permissions