Steinberg UR22 - Dropouts

[.t0x]

Audio Dropouts durch WLAN

Hi,

ich habe seit heute ein Audio Interface (Steinberg UR22) an meinem Rechner.
Leider plagen mich bei der Benutzung dabei viele Dropouts bei der Audio Wiedergabe.

Ich habe den halben Tag mit T&E und googlen rumprobiert. Dabei konnte ich kleinere Erfolge erzielen, jedoch komme ich
zu keiner endgueltigen Loesung.

Zwei Tools waren meine staetigen Begleiter:
DPC Latency Checker
LatencyMon

Erfolge konnte ich erzielen, in dem ich die Energiesparoptionen meines Desktop-PCs veraendert habe und
diverse Energiesparoptionen im BIOS deaktivert habe.
Die onboard Sound- und LAN Karte habe ich ebenfalls deaktiviert, wobei ich aus meinen Beobachtungen heraus sagen kann,
dass es zu keinerlei Veraenderungen in o.g. Tools kommt, wenn ich onboard Sound/LAN aktiviert habe.

Eben so kann ich sagen, dass es einen Treiber/Hardware-Konflikt geben muss, und es nicht mit meinem Audio-Interface
zu tun haben kann. Schließe ich dieses vom Rechner ab, spucken mir die Tools die selben Fehlermeldungen aus.
Verschiedene USB Ports habe ich ebenfalls ausprobiert. Das abschließen diverserer, sekundaerer Hardware vom Rechner
(wie Webcam, ext. HDD etc.) hat ebenfalls zu keinem Erfolg gefuehrt.

Ich habe ein Win7 64bit System welches auf folgende Hardware zurueck greift:
E8400
4GB Ram
Radeon 4800 HD
Gigabyte EP43-DS3L
TL-WN851ND

Folgende Treiber sind aktuell bzw. habe ich aktualisiert:
- Win7
- UR22
- Intel Chipsatz Treiber
- WLAN Karte

Kommen wir nun zum Interessanten: Sobald ich meine WLAN Karte im Geraetemanager deaktiviere, wird der Sound ohne
Fehler ausgegeben. DPC Latency Checker zeigt peaks durchgaengig im gruenen Bereich.
Allerdings spuckt mir LatencyMon noch immer (obwohl ich alle moeglichen Energiepsaroptionen angegangen bin) folgende
Meldung aus:

Your system appears to be having trouble handling real-time audio and other tasks. You are likely to experience buffer underruns appearing as drop outs, clicks or pops. One or more DPC routines that belong to a driver running in your system appear to be executing for too long. Also one or more ISR routines that belong to a driver running in your system appear to be executing for too long. Also your system appears to be having trouble which may be attributed to SMIs, IPIs, CPU bugs or unexplainable stalls. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates.

Das ich auf mein WLAN nur ungern verzichten moechte, sollte klar sein. Außerdem kann das ja auch kein Zustand sein,
auf WLAN verzichten zu muessen, weil ich mein externes USB Audiointerface nutzen moechte.

Ich bin mit meinem Latein echt am Ende. Daher dieser Thread.
Ich wuerde mich ueber Hilfe echt freuen.

VG,
.t0x

EDIT: Anbei mal noch der LatencyMon Log:

_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be having trouble handling real-time audio and other tasks. You are likely to experience buffer underruns appearing as drop outs, clicks or pops. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates.
LatencyMon has been analyzing your system for 0:01:46 (h:mm:ss) on all processors.


_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: SOUNDSYSTEM
OS version: Windows 7 Service Pack 1, 6.1, build: 7601 (x64)
Hardware: EP43-DS3L, Gigabyte Technology Co., Ltd.
CPU: GenuineIntel Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
Logical processors: 2
Processor groups: 1
RAM: 4094 MB total


_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 2999,0 MHz
Measured CPU speed: 2455,0 MHz (approx.)

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.


_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.

Highest measured interrupt to process latency (µs): 8070,952559
Average measured interrupt to process latency (µs): 2,685241

Highest measured interrupt to DPC latency (µs): 7343,498348
Average measured interrupt to DPC latency (µs): 0,589905


_________________________________________________________________________________________________________
MEASURED SMI, IPI AND CPU STALLS
_________________________________________________________________________________________________________
The SMI, IPI and CPU stalls value represents the highest measured interval that a CPU did not respond while having its maskable interrupts disabled.

Highest measured SMI or CPU stall (µs) 0,341368


_________________________________________________________________________________________________________
REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.

Highest ISR routine execution time (µs): 336,784261
Driver with highest ISR routine execution time: hal.dll - Hardware Abstraction Layer DLL, Microsoft Corporation

Highest reported total ISR routine time (%): 0,203776
Driver with highest ISR total time: hal.dll - Hardware Abstraction Layer DLL, Microsoft Corporation

Total time spent in ISRs (%) 0,273756

ISR count (execution time <250 µs): 135869
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-999 µs): 4
ISR count (execution time 1000-1999 µs): 0
ISR count (execution time 2000-3999 µs): 0
ISR count (execution time >=4000 µs): 0


_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.

Highest DPC routine execution time (µs): 214,535512
Driver with highest DPC routine execution time: tcpip.sys - TCP/IP-Treiber, Microsoft Corporation

Highest reported total DPC routine time (%): 0,194893
Driver with highest DPC total execution time: ataport.SYS - ATAPI Driver Extension, Microsoft Corporation

Total time spent in DPCs (%) 0,403698

DPC count (execution time <250 µs): 337014
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 0
DPC count (execution time 1000-1999 µs): 0
DPC count (execution time 2000-3999 µs): 0
DPC count (execution time >=4000 µs): 0


_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.

Process with highest pagefault count: taskhost.exe

Total number of hard pagefaults 11
Hard pagefault count of hardest hit process: 5
Highest hard pagefault resolution time (µs): 19783,470157
Total time spent in hard pagefaults (%): 0,054772
Number of processes hit: 4


_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 1,342110
CPU 0 ISR highest execution time (µs): 336,784261
CPU 0 ISR total execution time (s): 0,506342
CPU 0 ISR count: 122158
CPU 0 DPC highest execution time (µs): 214,535512
CPU 0 DPC total execution time (s): 0,575185
CPU 0 DPC count: 319611
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 0,594541
CPU 1 ISR highest execution time (µs): 47,10070
CPU 1 ISR total execution time (s): 0,074278
CPU 1 ISR count: 13715
CPU 1 DPC highest execution time (µs): 117,414138
CPU 1 DPC total execution time (s): 0,281033
CPU 1 DPC count: 17403
_________________________________________________________________________________________________________

 

[Mr.Zweig]

Haste mal den WLAN Treiber geupdated oder nen Alternativen probiert?

 

[.t0x]

Das habe ich wohl in meinem Schreibwahn verpeilt zu erwaehnen.
Die WLAN Treiber sind natuerlich ebenfalls aktuell.
Ich habe das WLAN Management zudem erst die TP Software uebernehmen lassen, dann auch mal Windows.
Beides fuehrte zu keinem Ergebnis.

Ergänzung (2. April 2013)

Ich habe mittlerweile die starke Vermutung, dass es am WLAN Background Scan liegt.
Aller ~60sec gibt es diese derben Latenzausfall. Nur wenn WLAN aktiviert ist.
Mit dem VGB-Tool und WLAN Optimizer bekomm ich besagten Scan leider nicht deaktiviert.
Hat irgendjmd. nen Tipp, wie ich das unter Win7 SP1 64bit hinbekomme?

Ergänzung (2. April 2013)

Ich habe den Threadtitel mal aktualisiert.

Ueber folgendes bin ich jetzt zufaellig gestolpert:

Lasse ich in der cmd einen ping laufen, liefert mir der DPC Latency Checker durchgehend gruene Peaks. Endet das Ping-Signal bzw. schließe
ich die Konsole, gibts die o.g. roten Ausschlaege aller ~60sec.

Kann damit irgendjmd. etwas anfangen bzw. eine Analogie zu ner WLAN Einstellung ziehen?!