Overclock.net › Forums › Components › Mice › Windows audio stack sucks, anything higher than stereo 16 bit 44.1k has higher cursor lag
New Posts  All Forums:Forum Nav:

Windows audio stack sucks, anything higher than stereo 16 bit 44.1k has higher cursor lag - Page 10  

post #91 of 258
Quote:
Originally Posted by HAGGARD View Post

microe's MouseTester software that was recently stickied. Gather results, plot them, look at interval vs. time. Post your results!

Edit: Oh yeah, remember to move your mouse fast enough to where you report at maximum polling rate. And zoom in on the data plot to sufficiently highlight poll time in microseconds. Also make sure to test for both active and inactive audio playback.
Thanks - I somehow missed that option when I looked at MouseTester.
Well that was interesting. There seemed to be little difference in polling rates when playing back music, whether using WASAPI, DirectSound, or ASIO to my USB DAC.
Polling "jitter" is increased by about ±50%. So polling at 1000Hz you get 1-1.5ms, polling at 500Hz and I was seeing results of 1-3ms rather than being fixed at 2ms for example.
Edit: I should mention that the results looked nothing like yours Haggard - I ended up with essentially three straight lines - the polling rate (e.g. 2ms) and the over/undershoot of 50%. (1 & 3ms)

When doing anything that starts/stops playback there is a small spike in latency (an additional 1-2ms) and using larger audio buffers seems to minimize that.
However there was a massive difference when playing back audio via Kernel Streaming - at both extremes.

With the Kernel Streaming buffer size set to 1s, mouse polling was completely unaffected by music playback, changing tracks etc.
With the Kernel Streaming buffer set to 0.05s, mouse polling is affected significantly - essentially random like your image - with the highest latency I recorded being 14ms!

If it matters, these tests were done using the latest version of JRiver for playback.

However, I am not sure that this proves there is a detectable effect on mouse movements. No-one here has a screen which is updating at 1000Hz, and if you're using an LCD the minimum response time you're actually going to get is probably something like 4ms and could be well above 10ms if you're not using ULMB.

And in theory, you actually want the mouse polled at the last possible moment before the screen updates for the most responsive movement.
Quote:
Originally Posted by Trull View Post

The difference from my Xonar DX with the UNI Xonar drivers with low DPC latency (which I'm pretty sure all it does is not initialize the ASUS Audio Center) to the Sound Blaster Z with the Windows UAA driver was huge.

I'm looking forward to seeing how the X-Fi compares to the Sound Blaster Z, and I'll just stick to the one that sounds better if there's not much of a difference. We'll see.
Yep, the Xonar drivers are garbage. I was getting DPC latency spikes of 800µs with Dolby Headphone enabled on a DGX! Sound Blaster Z should offer the best latency since it actually uses hardware acceleration for a lot of its processing.
Edited by NotAgain - 1/17/15 at 3:45am
post #92 of 258
Very interesting; thanks for reporting back. Would be interested in seeing graphs. You can also more precisely check poll times by saving the data to a log file with the program.

I guess it is somewhat comforting to kow that you can achieve rather stable polls during audio playback over USB. I expected that to completely mess with the intervals. It's also interesting that you apparently get no constant variance in the microsecond-range like I do, but stable variance. Could come down to the USB controllers, CPU or maybe even the way of setting the poll interval (with the WMO I have to use hidusbf.sys, maybe mice that natively request to be polled at 1kHz are handled differently there).
I can't see why 1-3ms poll times would show up with a 500Hz interval though.
Kernel streaming and buffer sizes I suspect make a difference for you mostly because of your playback device being USB. Increasing the buffer size allows for periodic data calls of the endpoint to be less frequent, i. e. less demanding on your USB controller in terms of task timing. Does your DAC share the controller with your mouse btw.?
post #93 of 258
Quote:
Originally Posted by HAGGARD View Post

I can't see why 1-3ms poll times would show up with a 500Hz interval though.
To test 500Hz I used my G602, so I'm guessing that's a quirk of it being wireless.
My guess would be that the receiver actually updates at 1000Hz, while the mouse transmits at 500Hz. (or 125Hz in Eco mode)
So the mouse itself always updates at a steady 2ms, but if the DAC causes an update from the USB receiver to be late (3ms) the next update from the mouse is seen as coming in early. (1ms)
Quote:
Originally Posted by HAGGARD View Post

Kernel streaming and buffer sizes I suspect make a difference for you mostly because of your playback device being USB. Increasing the buffer size allows for periodic data calls of the endpoint to be less frequent, i. e. less demanding on your USB controller in terms of task timing. Does your DAC share the controller with your mouse btw.?
Yes, they're on the same hub.
post #94 of 258
On the same controller as well though? Device Manager -> View -> Devices by connection.
post #95 of 258
Quote:
Originally Posted by HAGGARD View Post

Very interesting; thanks for reporting back. Would be interested in seeing graphs. You can also more precisely check poll times by saving the data to a log file with the program.

I guess it is somewhat comforting to kow that you can achieve rather stable polls during audio playback over USB. I expected that to completely mess with the intervals. It's also interesting that you apparently get no constant variance in the microsecond-range like I do, but stable variance. Could come down to the USB controllers, CPU or maybe even the way of setting the poll interval (with the WMO I have to use hidusbf.sys, maybe mice that natively request to be polled at 1kHz are handled differently there).
I can't see why 1-3ms poll times would show up with a 500Hz interval though.
Kernel streaming and buffer sizes I suspect make a difference for you mostly because of your playback device being USB. Increasing the buffer size allows for periodic data calls of the endpoint to be less frequent, i. e. less demanding on your USB controller in terms of task timing. Does your DAC share the controller with your mouse btw.?



How do I make sure I'm not using the same USB controler? I'm using a driverless USB1.0 Asus U5 here.

Edit: Oh, nevermind, you already answered it.


One thing that I noticed, is that when I use the Xonar U5 with driver on USB2.0 mode, I get 2-2.5% of CPU usage. On USB1.0 mode without the driver I get 0.5-1% max cpu usage.
Edited by plyr - 1/17/15 at 6:38am
post #96 of 258
Quote:
Originally Posted by Trull View Post

The difference from my Xonar DX with the UNI Xonar drivers with low DPC latency (which I'm pretty sure all it does is not initialize the ASUS Audio Center) to the Sound Blaster Z with the Windows UAA driver was huge.

I'm looking forward to seeing how the X-Fi compares to the Sound Blaster Z, and I'll just stick to the one that sounds better if there's not much of a difference. We'll see.

interesting... I will try X-Fi or SB:Z too then, because I have only troubles with my xonar DX. I have PCI-E slots for xonard dx too close to my graphics card and if GPU is in load, than somehow it emits a lot of interference to my xonar. It causes "helicopter sound" on the background when I speak on TS and a little bit of interference in output sound too... I have gtx970 which has more of coil whine than my previous graphics card and that's the reason, why these issues are much worse now.
Edited by leakydog - 1/17/15 at 7:06am
post #97 of 258
Quote:
Originally Posted by leakydog View Post

interesting... I will try X-Fi or SB:Z too then, because I have only troubles with my xonar DX. I have PCI-E slots for xonard dx too close to my graphics card and if GPU is in load, than somehow it emits a lot of interference to my xonar. It causes "helicopter sound" on the background when I speak on TS and a little bit of interference in output sound too... I have gtx970 which has more of coil whine than my previous graphics card and that's the reason, why these issues are much worse now.

I have never been able to figure that issue out and it wasn't being to close to the GPU or sharing an IRQ either.

In the end I've resolved that using my onboard for input (audio) and Essence ST ASUS for output. Funny enough it only happened when the GPU was under more "load", aka during gameplay. Once on the desktop everything was back to normal.

It also became worse in more graphically intense games (BF vs CSGO).
Desktop (Main)
(21 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i7 5820K ASUS X99-A/USB 3.1  ASUS ROG Strix GeForce GTX 1080 Kingston HyperX 16GB 3Ghz  
Hard DriveHard DriveHard DriveHard Drive
Samsung 840 Pro Seagate Barracuda 1.5 TB Seagate Barracuda 2.0 TB Seagate Barracuda 4TB 
Hard DriveOptical DriveCoolingOS
Seagate Barracuda 4TB Le random dvd writer Corsair Hydro Series™ H100i Windows 10 Professional 64 bit 
MonitorKeyboardPowerCase
iiyama ProLite G2773HS Corsair K70 Super Flower 1200W (Platinum) Corsair 600T Black 
MouseMouse PadAudioAudio
Nixeus Revel Allsop Raindrop XL ASUS Xonar Essence STXII Sennheiser HD650 
Audio
Musical Fidelity X-Can v3 
  hide details  
Desktop (Main)
(21 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i7 5820K ASUS X99-A/USB 3.1  ASUS ROG Strix GeForce GTX 1080 Kingston HyperX 16GB 3Ghz  
Hard DriveHard DriveHard DriveHard Drive
Samsung 840 Pro Seagate Barracuda 1.5 TB Seagate Barracuda 2.0 TB Seagate Barracuda 4TB 
Hard DriveOptical DriveCoolingOS
Seagate Barracuda 4TB Le random dvd writer Corsair Hydro Series™ H100i Windows 10 Professional 64 bit 
MonitorKeyboardPowerCase
iiyama ProLite G2773HS Corsair K70 Super Flower 1200W (Platinum) Corsair 600T Black 
MouseMouse PadAudioAudio
Nixeus Revel Allsop Raindrop XL ASUS Xonar Essence STXII Sennheiser HD650 
Audio
Musical Fidelity X-Can v3 
  hide details  
post #98 of 258
Quote:
Originally Posted by CorruptBE View Post

I have never been able to figure that issue out and it wasn't being to close to the GPU or sharing an IRQ either.

In the end I've resolved that using my onboard for input (audio) and Essence ST ASUS for output. Funny enough it only happened when the GPU was under more "load", aka during gameplay. Once on the desktop everything was back to normal.

It also became worse in more graphically intense games (BF vs CSGO).
Speakers or headphones? If it's speakers you probably have a ground loop, and ground loop isolating audio cables should fix the problem. Audio cables not power cables - anything which removes the ground (safety) from power is dangerous.
post #99 of 258
I use the Speaker OUT on the Essence ST with 2 seperate Left/Right cables towards and External AMP which then has a Headphone hooked up to it.
Desktop (Main)
(21 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i7 5820K ASUS X99-A/USB 3.1  ASUS ROG Strix GeForce GTX 1080 Kingston HyperX 16GB 3Ghz  
Hard DriveHard DriveHard DriveHard Drive
Samsung 840 Pro Seagate Barracuda 1.5 TB Seagate Barracuda 2.0 TB Seagate Barracuda 4TB 
Hard DriveOptical DriveCoolingOS
Seagate Barracuda 4TB Le random dvd writer Corsair Hydro Series™ H100i Windows 10 Professional 64 bit 
MonitorKeyboardPowerCase
iiyama ProLite G2773HS Corsair K70 Super Flower 1200W (Platinum) Corsair 600T Black 
MouseMouse PadAudioAudio
Nixeus Revel Allsop Raindrop XL ASUS Xonar Essence STXII Sennheiser HD650 
Audio
Musical Fidelity X-Can v3 
  hide details  
Desktop (Main)
(21 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i7 5820K ASUS X99-A/USB 3.1  ASUS ROG Strix GeForce GTX 1080 Kingston HyperX 16GB 3Ghz  
Hard DriveHard DriveHard DriveHard Drive
Samsung 840 Pro Seagate Barracuda 1.5 TB Seagate Barracuda 2.0 TB Seagate Barracuda 4TB 
Hard DriveOptical DriveCoolingOS
Seagate Barracuda 4TB Le random dvd writer Corsair Hydro Series™ H100i Windows 10 Professional 64 bit 
MonitorKeyboardPowerCase
iiyama ProLite G2773HS Corsair K70 Super Flower 1200W (Platinum) Corsair 600T Black 
MouseMouse PadAudioAudio
Nixeus Revel Allsop Raindrop XL ASUS Xonar Essence STXII Sennheiser HD650 
Audio
Musical Fidelity X-Can v3 
  hide details  
post #100 of 258
I know what's going on here based on my researches while I was having that awkward mouse problem. No matter how we check Device Manager for IRQ conflicts, it generally does not tell us the whole story. I don't know whether all the motherboard manufacturers adding this detail into their manual or not but you might want to check yours.

So this one is for Asus M5A99FX Pro R2.0


I have a Creative Zx but I have massive, utter, incredible input and mouse lag going on whenever I use PCIe x16_4 port for my soundcard which is the only port I can use for my soundcard because my HUGE Zotac GTX470 AMP is taking nearly all the slots there. I tried to put soundcard in PCIe x1 slot and put video card another slot than the first one but i cannot get video like that.

All motherboards have different physical IRQ sharing table like that and you can find Asus ones on their manual.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Mice
  • Windows audio stack sucks, anything higher than stereo 16 bit 44.1k has higher cursor lag
This thread is locked  
Overclock.net › Forums › Components › Mice › Windows audio stack sucks, anything higher than stereo 16 bit 44.1k has higher cursor lag