Audio crackling in ASIO is driving me up the wall.

[crashby]

Ever since I've upgraded to 7 there has been a problem with audio crackling in ASIO. Even with a large buffer there is audio crackling during playback. This was never a problem using Music Creator Touch. In fact loading songs created in 7 into Touch, plays back with no problems, although they are missing the new "effects", Max, Wide and Grit. These effects seem to cause problems too.

CPU never really goes much about 5%, but 7 is unusable, as to get any kind of audio stability requires maxing the buffers, but this messes latency big time.

I'm running a gaming laptop with Realtek HD. I've tried ASIO4All, Realtek native drivers, and even using an external USB sound device (a Line 6 guitarport).

Everything works fine with Music Creator Touch, but whatever method I use in 7, gives crackling audio.

Anyone else experience this problem?

[GibsonPro-Audio]

引用自 crashby：

I'm running an MSI GE62 2AF Apache Pro laptop with an i7, and 16GB RAM, also with SSD and HDD, OS on SSD, cakewalk on HDD. Win 10 64-bit

Also, a few thoughts.

Cakewalks on an external drive correct?

What's the speed and R/W capacity of that drive?

Are you also recording audio to that drive?

Are you running a USB hub at all?

[crashby]

I did all that and now my existing songs aren't playing properly. The tracks are there but no sound is playing. Some songs have some parts play, but others are mute. If I start a new song and add instruments it works. If I add instruments to existing songs there is no audio

[crashby]

And it still crackles with just one track playing on GuitarPort. I hope I am able to recover my songs

[GibsonPro-Audio]

引用自 crashby：

And it still crackles with just one track playing on GuitarPort. I hope I am able to recover my songs

Yes, its likely your projects were saved with ASIO4ALL as the outputs instead of the Line6. Nothing is lost in your projects, you'll just need to make sure the outputs are set according in the project. This can be reviewed in the Console view.

Have you tried Latencymon yet?

[crashby]

I can't recover this. I put back ASIO4ALL and I can't get my song to play again. Some files work but some don't

[crashby]

Never mind. User error

[crashby]

Incedentally ASIO improved when I switched to 44.1Khz

[GibsonPro-Audio]

引用自 crashby：

I can't recover this. I put back ASIO4ALL and I can't get my song to play again. Some files work but some don't

Nothing will be lost in the projects. Routing is saved separately from audio/midi data.

Again, ASIO4ALL isn't really designed for the Line6 Guitarport, so you'll likely have bad performance with distortion, driver conflicts etc. We don't recommend using it with that hardware.

引用自 crashby：

Everything is routed through Bus A, but only the bass will play :(

A quick way to reassign multiple tracks:

1. Click on track 1,
2. Press Control+A, to select all the tracks
3. Holding the Control button, in the output section of an audio track, select bus A. This should change all of the track outputs to the same bus.
4. Make sure the bus is set to the correct audio outputs.

I'd like to see if you can get LatencyMon going and see what the report says.

[GibsonPro-Audio]

When you get a chance could you fill in these for me? This is all info we need to know to properly diagnose the issue.

引用自 Seth Kellogg Cakewalk：

引用自 crashby：

I'm running an MSI GE62 2AF Apache Pro laptop with an i7, and 16GB RAM, also with SSD and HDD, OS on SSD, cakewalk on HDD. Win 10 64-bit

Also, a few thoughts.

Cakewalks on an external drive correct?

What's the speed and R/W capacity of that drive?

Are you also recording audio to that drive?

Are you running a USB hub at all?

[crashby]

Cakewalk is running on internal HDD. No idea speeds. It's a gaming laptop, so very high spec. No audio recording attempted so far.

No usb hub. Plenty of ports.

Latency Mon reports

_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be suitable for handling real-time audio and other tasks without dropouts.
LatencyMon has been analyzing your system for 0:00:47 (h:mm:ss) on all processors.


_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: MSI
OS version: Windows 10 , 10.0, build: 14393 (x64)
Hardware: GE62 2QF, Micro-Star International Co., Ltd., MS-16J1
CPU: GenuineIntel Intel(R) Core(TM) i7-5700HQ CPU @ 2.70GHz
Logical processors: 8
Processor groups: 1
RAM: 16299 MB total


_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 2694 MHz

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): 199.192056
Average measured interrupt to process latency (µs): 3.331757

Highest measured interrupt to DPC latency (µs): 196.911231
Average measured interrupt to DPC latency (µs): 0.687761


_________________________________________________________________________________________________________
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): 18.712695
Driver with highest ISR routine execution time: HDAudBus.sys - High Definition Audio Bus Driver, Microsoft Corporation

Highest reported total ISR routine time (%): 0.000462
Driver with highest ISR total time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation

Total time spent in ISRs (%) 0.000743

ISR count (execution time <250 µs): 2674
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-999 µs): 0
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): 191.877506
Driver with highest DPC routine execution time: ndis.sys - Network Driver Interface Specification (NDIS), Microsoft Corporation

Highest reported total DPC routine time (%): 0.019751
Driver with highest DPC total execution time: rspLLL64.sys - Resplendence Latency Monitoring and Auxiliary Kernel Library, Resplendence Software Projects Sp.

Total time spent in DPCs (%) 0.064353

DPC count (execution time <250 µs): 220418
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.


Process with highest pagefault count: latmon.exe

Total number of hard pagefaults 153
Hard pagefault count of hardest hit process: 66
Highest hard pagefault resolution time (µs): 695.908686
Total time spent in hard pagefaults (%): 0.009796
Number of processes hit: 5


_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 1.157304
CPU 0 ISR highest execution time (µs): 18.712695
CPU 0 ISR total execution time (s): 0.002195
CPU 0 ISR count: 1492
CPU 0 DPC highest execution time (µs): 191.877506
CPU 0 DPC total execution time (s): 0.215962
CPU 0 DPC count: 214140
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 0.751907
CPU 1 ISR highest execution time (µs): 1.885301
CPU 1 ISR total execution time (s): 0.000323
CPU 1 ISR count: 692
CPU 1 DPC highest execution time (µs): 99.059020
CPU 1 DPC total execution time (s): 0.001765
CPU 1 DPC count: 534
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 0.436767
CPU 2 ISR highest execution time (µs): 1.101336
CPU 2 ISR total execution time (s): 0.000027
CPU 2 ISR count: 58
CPU 2 DPC highest execution time (µs): 103.636971
CPU 2 DPC total execution time (s): 0.004697
CPU 2 DPC count: 1162
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 0.681256
CPU 3 ISR highest execution time (µs): 1.457684
CPU 3 ISR total execution time (s): 0.000091
CPU 3 ISR count: 142
CPU 3 DPC highest execution time (µs): 107.315145
CPU 3 DPC total execution time (s): 0.003041
CPU 3 DPC count: 770
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s): 0.515554
CPU 4 ISR highest execution time (µs): 0.996659
CPU 4 ISR total execution time (s): 0.000034
CPU 4 ISR count: 67
CPU 4 DPC highest execution time (µs): 28.491091
CPU 4 DPC total execution time (s): 0.004230
CPU 4 DPC count: 1138
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s): 0.697158
CPU 5 ISR highest execution time (µs): 1.388641
CPU 5 ISR total execution time (s): 0.000057
CPU 5 ISR count: 106
CPU 5 DPC highest execution time (µs): 91.615813
CPU 5 DPC total execution time (s): 0.003788
CPU 5 DPC count: 819
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s): 0.431814
CPU 6 ISR highest execution time (µs): 1.750557
CPU 6 ISR total execution time (s): 0.000026
CPU 6 ISR count: 48
CPU 6 DPC highest execution time (µs): 82.937639
CPU 6 DPC total execution time (s): 0.005147
CPU 6 DPC count: 1192
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s): 0.637562
CPU 7 ISR highest execution time (µs): 1.326281
CPU 7 ISR total execution time (s): 0.000043
CPU 7 ISR count: 69
CPU 7 DPC highest execution time (µs): 44.589087
CPU 7 DPC total execution time (s): 0.003422
CPU 7 DPC count: 663
_________________________________________________________________________________________________________

[GibsonPro-Audio]

Thanks this is all helpful info.

引用自 crashby：

Incedentally ASIO improved when I switched to 44.1Khz

If you're in ASIO4ALL, that's probably pretty expected. It's basically accessing the hardware through the Windows core driver, which could have competition for exclusive control.

Windows tends to run in 48khz, and built in audio hardware can be hijacked by system notifications. I'd recommend testing with notifications off for a bit to isolate any potential contributing factors. https://www.howtogeek.com/219703/how-to-disable-notification-sounds-in-windows-10/

Also, are you using a wired NIC or Wireless? Have you experimented with it on/off?

Looking into the Guitarport a bit, users seemed to have similar issues in W10 with the older drivers.
Are you using this one? http://line6.com/software/?submit=Show&name=Line+6+Monkey
Download Link: http://line6.com/getrelease?rid=6996

[GibsonPro-Audio]

Are your projects mostly audio with FX, or Virtual Instruments with FX added?

[crashby]

Running at 44.1Kz with ASIO4ALL seems reasonably OK at the minute. Guitar Port performance is *terrible*. I believe I have the most recent drivers, but it's not really supported any more so I am not getting my hopes up.