Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#282 Loss of DirectSound device causes lag

closed
nobody
Mumble (544)
5
2012-10-30
2009-04-29
Pilot_51
No

When Mumble loses the DirectSound device for both input and output, it causes lag in the system including slow responsiveness and jumpy mouse. In my case I changed multi-streaming settings on my Realtek HD for either input or output. There is no indication of unusual CPU usage from mumble.exe. When going into the config and resetting the device, the lag goes away. Nothing was logged in Console.txt at the time. I should note that I run Folding@Home at 45% per CPU core (idle priority), which can cause a bottleneck in certain circumstances; Mumble runs on both cores at high priority. Closing the Folding@Home processes eliminated most of the lag. I would guess Mumble is making short but high demands on the CPU, too short to be easily seen in Task Manager but sudden enough that Folding@Home can't get out of the way quick enough to prevent lag. Since many games or programs use a similar amount of CPU as Folding@Home, I wouldn't be surprised if the same problem would occur in other likely situations.

Mumble version: 1.1.8 and snapshot 2009-04-29-1900-cff157
OS: Windows XP Home SP3
Audio input/output: Realtek HD

Discussion

  • This sounds like a driver bug; if you remove the device, DS should return errors to Mumble, but it seems in your case it does not, it just continous to try the removed device. This is a OS/driver issue, and hence nothing we can do anything about.

     
  • Pilot_51
    Pilot_51
    2009-04-30

    The log pane does show that both input and output devices are lost.

     
  • In that case I'm unable to replicate the problem; trying something similar here just pops up the error message then happily returns to idle state. Check if Mumble's CPU usage time and IO requests increase; that will increase even if the task monitor is "fooled" into showing a low CPU %.

     
  • Pilot_51
    Pilot_51
    2009-04-30

    I ran 3 tests (1 base test without losing device) with switching between multi-streaming recording, here are the results:

    Base test (2:21:30 - 2:22:30)
    CPU Time: 0:00:20 to 0:00:21 = 1 second
    Mem Usage: 16,368 K to 16,376 K = +8 K
    Handles: 719 to 720 = +1
    Threads: 17 (no change)
    I/O Reads: 23,712 to 24,702 = 990
    I/O Read Bytes: 3,994,168 to 4,003,078 = 8,910
    I/O Writes: 48 (no change)
    I/O Write Bytes: 3,778 (no change)
    I/O Other: 472,424 to 490,441 = 18,017
    I/O Other Bytes: 15,821,416 to 16,395,762 = 574,346

    Test 1 (2:24:00 - 2:25:00): Lose devices at 2:24:09
    CPU Time: 0:00:22 to 0:00:23 = 1 second
    Mem Usage: 16,380 K to 16,292 K = -88 K
    Handles: 720 to 634 = -86
    Threads: 17 to 14 = -3
    I/O Reads: 26,195 to 27,188 = 993
    I/O Read Bytes: 4,016,515 to 4,025,452 = 8,937
    I/O Writes: 48 to 50 = 2
    I/O Write Bytes: 3,778 to 3,907 = 129
    I/O Other: 516,002 to 519,408 = 3,406
    I/O Other Bytes: 17,210,888 to 17,319,066 = 108,178

    Test 2 (2:28:00 - 2:29:00): Lose devices at 2:28:26
    CPU Time: 0:00:25 to 0:00:26 = 1 second
    Mem Usage: 16,416 K to 16,304 K = -112 K
    Handles: 721 to 637 = -84
    Threads: 17 to 14 = -3
    I/O Reads: 29,826 to 30,881 = 1,055
    I/O Read Bytes: 4,050,664 to 4,060,159 = 9,495
    I/O Writes: 54 to 56 = 2
    I/O Write Bytes: 4,220 to 4,349 = 129
    I/O Other: 564,705 to 571,746 = 7,041
    I/O Other Bytes: 18,868,839 to 19,092,903 = 224,064

    So in summary...
    CPU Time is consistent (accurate to the second of course).
    Mem Usage drops ~100 K as soon as devices are lost.
    Handles drop ~85 as soon as devices are lost.
    Threads drop 3 from 17 to 14 as soon as devices are lost.
    I/O Reads don't change much from normal.
    There are 2 I/O Writes totaling 129 bytes as soon as devices are lost.
    I/O Other is considerably lower.

    I don't see anything there indicating a cause, but the lag is definitely related to Mumble for the reasons I've previously mentioned (resetting in config eliminates the lag).

    When I boot into Win7 I'll see if I can reproduce it there.

     
  • Pilot_51
    Pilot_51
    2009-05-02

    I have not been able to reproduce this in Win7. Mumble never indicates the loss of devices, it switches immediately to Default Device when it loses the device it was set on.

     
  • I'm not able to reproduce this. If the log shows "device lost", the device is released, and Mumble is no longer polling it.
    I've changed the initialization a bit, in case your driver has threading issues (which it shouldn't), so you can see if this improves things once 1.2 is out.