#298 push to talk doesn't work after suspend

Mumble (544)

If I leave mumble on when I suspend my computer (windows XP pro 32 bit, up to date w/ patches), the side mouse button I have set to push to talk doesn't work until I quit mumble and relaunch. I have seen this behavior a few times so I know it is repeatable, but I am not sure if it is completely consistant yet.
Mouse is a Intellimouse optical USB. I have not tried it with a keyboard push to talk key so I don't know if that is also affected. (Just though of that while I was typing up this bug)


  • Thorvald Natvig

    Thorvald Natvig - 2009-06-20

    Which versions?

    Do other shortcuts work?

    Will it start working again if you go into the settings and click "apply"?

  • M^3

    M^3 - 2009-06-20

    I am using the current release version 1.1.8

    I will check other shortcuts when I get the chance, and also the settings (re)apply.

  • M^3

    M^3 - 2009-06-20

    did some more testing- here are my notes

    after fresh bootup , some general computer use (both mouse short-cuts worked) and then suspend . . .
    accidentially left settings window open when setting to suspend.

    when woke up, PTT and alt-PTT did not work.
    cancelled the settings window and both ptt and alt-ptt still didn't work
    (both are assigned to different side-mouse buttons w/ suppress checked).
    reopened settings window, went to short-cuts, pressed apply, mumble stopped responding.
    relaunched mumble and both short-cuts worked again.
    added a keyboard short-cut for mute self (keypad *, keyboard is PS-2 not USB)

    Next wake up, waited about 10 minutes before trying the short-cuts, all worked first try
    (did ptt, alt-ptt and mute self in that order).

    next wake up, worked perfectly right away. I wonder if this is affected by having a keyboard short-cut also assigned?

    next wake up, immediate test was a no-go for mouse, keyboard short-cut worked fine.
    goint to short-cut settins and pressing apply had no affect, but after clicking ok, the mouse button short-cuts worked again.
    and the keyboard short-cut continued to work.

    next wake up, initial mouse button short-cut** tests, not working, keypad short-cut is working.
    going into settings on the short-cut page and pressing "ok" resulted in temporary freeze of mumble.
    pressing "apply" did nothing, pressing "ok" again unfroze and closed settings window (could have also just been a matter of time before the unfreeze)
    Mouse and keyboard short-cuts all work again.

  • Thorvald Natvig

    Thorvald Natvig - 2009-07-03

    Button 3+ is not properly supported by the lowlevel windows input, only by directinput. When you suspend, non-generic (aka; device-specific) devices are removed from the system; they cease to exist and appear as newly connected devices a short while after you've finished resuming.
    I've added some code which should discover "new" devices and reiterate the list.

  • M^3

    M^3 - 2009-07-04

    Not fixed in current snapshot 1c6ac0, I didn't test the one from earlier today, though I can if you request me to, I have not deleted that installer yet.
    When I went into the shortcut config and simply pressed "Apply", it hung mumble 's interface for 15-20 seconds before it then started working again. While it would be nice to have this fixed, please don't make it a priority, I doubt many people will be affected by this issue.

  • Thorvald Natvig

    Thorvald Natvig - 2009-07-06

    Could you post what the console.txt log says?

  • M^3

    M^3 - 2009-07-09

    the most recent stuff in the console.txt was in my "c:\program files\mumble\"
    folder, not the "C:\Program Files\Mumble-1.2-ss" folder I made for testing.
    It didn't look relevant, but here it is:
    <W>2009-07-05 20:27:10.046 WASAPIInit: Requires Vista SP1
    <W>2009-07-05 20:27:10.046 ASIO: No valid devices found, disabling
    <W>2009-07-05 20:27:10.109 G15LCDEngine_win: Logitech LCD Manager not detected.
    <W>2009-07-05 20:27:10.109 Locale is en_US
    <W>2009-07-05 20:27:10.718 OpenSSL Support: 1
    <W>2009-07-05 20:27:10.718 ServerHandler: Failed to load qWave.dll, no QoS available
    <W>2009-07-05 20:27:10.937 Adding device {6f1d2b60-d5a0-11cf-bfc7-444553540000} Mouse Mouse:5
    <W>2009-07-05 20:27:10.953 Adding device {6f1d2b61-d5a0-11cf-bfc7-444553540000} Keyboard Keyboard:127
    <W>2009-07-05 20:27:11.156 DXAudioInput: Initialized
    <W>2009-07-05 20:27:11.171 DXAudioOutput: Primary buffer of 16000 Hz, 1 channels, 16 bits
    <W>2009-07-05 20:27:11.171 DXAudioOutputPlayer: New 16000Hz output buffer of 32000 bytes
    <W>2009-07-05 20:27:11.171 AudioOutput: Initialized 1 channel 16000 hz mixer

    By the way, the new snapshot from today worked the 1st time I tried it, but it took a while for it to start working again (more than 10-20 seconds I stopped checking after that and went back a while later)

  • M^3

    M^3 - 2009-07-09

    ok, the previous 3 times it seemed to work fine after suspend, sometimes a little sluggish at first, but understandable. This last time (the 4th time) it work sluggish at first, then it stopped working at all until I went into settings and just pressed "ok" on the shortcut page. kinda weird.

  • M^3

    M^3 - 2009-07-16

    Are you interested in a dmp file I for from procdump of mumble hung after "ok" in settings after resuming from stand-by? It is a little over 500k compressed so I cannot attach it here.

  • Thorvald Natvig

    Thorvald Natvig - 2010-07-18

    Does this still happen on current snapshots?
    And .. err. can you test it in Win 7?

  • M^3

    M^3 - 2010-07-23

    I have not tried the snapshots in quite a while actually, I will try to soon. I have windows 7 32 bit at work so I can try it there when I get the chance, but that might be a while, I just came back from a weeks vacation to lots of work and i believe that our department (IT) is understaffed contrary to what my boss believes. Maybe during lunch sometime if I don't work though it.

  • M^3

    M^3 - 2010-07-24

    well, I have not looked at seven yet, but on my home system the build marked 7208fc still misbehaves after waking up the computer. the push to talk worked fine on first launce, did nothing after waking from stand-by and clicking 'ok' after opening the preferences for short cuts (without changing anything) caused mumble to hang altogether. I left it hanging for over an hour just to make sure. This is only my first test but it isn't promising.

  • M^3

    M^3 - 2010-07-26

    if I manually reset the shortcut after wake up it does appear to work, just not until I do so. This is of course just my second test so I don't know how reproducible it is.
    On the snarl dev list they have been discussing registering for the acpi event notifications related to stand-by and hibernation in relation to an unrelated feature there but it got me thinking maybe this would also give a direction for eliminating this bug.

  • M^3

    M^3 - 2010-08-20

    tentative good news - the snapshot that I updated to last night worked this morning after being suspended all night. Only the briefest of tests, I will try to check it more extensively soon.

  • M^3

    M^3 - 2010-08-21

    bad news. second wake-up after standby with the same instance did not respond to mouse shortcut and then hung when I opened and closed the prefs for shortcuts.

  • M^3

    M^3 - 2010-08-22

    Ok, so it (push-to-talk) worked this time after stand-by and wake up. intermittently it is working.

  • Jonathan

    Jonathan - 2010-12-01

    I have the same problem using Windows 7 and Logitech G9. I am using mouse 3 which is configured as "generic button". The problem occurs consistent. I am using the newest snapshot. I have no problems when binding to a keyboard shortcut.

  • Anonymous - 2011-12-26

    I can confirm this issue happening on both my desktop and laptop. Both machines are Windows 7 65-bit, both are using Mumble 1.2.3 stable, and both use the standard left Alt key for Push-To-Talk. The issue is reproducible 100% of the time, for either computer, when following this procedure:

    1) Open Mumble, connect to a server
    2) Observe that the Alt push-to-talk keybind works as intended
    3) Put the machine to sleep through the Windows start menu
    4) Turn on the machine again via the power button
    5) Observe that the Alt kebyind does nothing.

    At this point, either of these two actions will fix the issue:
    A) Quit mumble, start it again, and re-connect to server.
    B) Go into configuration and re-define the hotkey (EG, click on the bind window and hit Alt, then hit OK).

    These actions do NOT fix the issue:
    A) Disconnecting and re-connecting to the server without exiting Mumble
    B) Changing channels

    This is a very annoying issue; please let me know what I can do to assist.

  • Anonymous - 2011-12-26

    Correction: hopefully it was obvious I meant to say "Windows 7 64-bit", not 65.

  • sqwishy

    sqwishy - 2013-08-05

    It looks like this hasn't been touched in a while, but the ticket is still open and both me and my friends have encountered this issue.

    I noticed the other day, when using teamspeak after suspending and resuming a Windows 7 64 bit machine, that I couldn't communicate because teamspeak couldn't acquire the recording device or something along those lines. So I checked in mumble and nothing seems to work on continuous mode either. I suspect that, in some of these cases, the issue isn't with key bindings or even mumble in particular.

  • Kissaki

    Kissaki - 2013-12-16
    • status: open --> invalid
    • Version: --> unspecified
    • Targeted Release: --> unspecified
  • Kissaki

    Kissaki - 2013-12-16

    Closed as invalid as no reply.