Hello, I just switched back to ASIO4ALL as the UMC ASIO driver Behringer provides for my U-Phoria 1820 interface causes performance issues and ASIO4ALL handles the load much better. However I have the issue that GP will suffer what I first thought were drop outs but actually are complete freezes where even the clock will stop and incoming midi will not be processed. I’d say they last for about 0.5 seconds. The CPU meter of GP will briefly go to a 100% then. I already closed all the applications that might cause interference but oddly it seems that the WIFI adapter is the cause of the problem. When I deactivate it the freezes seem to stop.
Usually I’d say I will just go to flight mode with the laptop when using it for live performances but I need to keep a WIFI connection with my rack mixer to control my monitor mix during performance, so that’s not an option. Any advice how to approach this issue otherwise?
Gig Performer doesn’t know anything about your wifi connection — nor does it even try to connect to our servers unless you have performed a system update that might make GP think the computer has changed. Are you using OSC with Gig Performer? Perhaps sending or receiving huge amounts of data?
Perhaps one of your other plugins is trying to connect to its home servers and holding things up.
Or perhaps a different wifi adapter?
How are you doing this? Is GP involved or are you running a separate application?
My guess was that ASIO4ALL is doing something weird on system level as in my understanding the ASIO driver operates on hardware level and not on OS level. But I think this might have been a false guess anyways, I now reactivated the WIFI function and the problem is gone. However now it seems that some channels are dead. It doesn’t seem a hardware issue though. I’m using the latest version of ASIO4ALL for Windows, so this is a bit surprising.
I use a client that connects to the mixer API using a network provided by the mixer. It’s not connected
currently though, I can test it tonight before my rehearsal.
There have been cases Wifi drivers clogging the dpc-queue on Windows, something like 65 ms. or so. So while GP is not the culprit, the audio might be hindered by the Wifi-driver. But this problem was wellknown about 10-15 years ago and one might hope it has been solved (although switching off Wifi also helps against unexpected Windows updates).
When it comes to asio4all, I’m not too excited about it, but when it does the trick… Who am I…?
Were you having issues when using Behringer drivers version 5 onwards? I seem to remember someone saying there were issues with versions above 5, and when they reverted to the latest version 4 driver, their problems were fixed. So might be worth giving a version 4 driver a shot…
I think that this has happened to me. I recently changed to Ethernet from wifi because I was getting audio dropouts in a high wifi area near the centre of town. Ethernet seems to be more stable.
Hello, thanks for all the replies! Although there are suspicious spikes in network activity during the events described I don’t think that there is an actual interference of the network adapter. However, that doesn’t solve my problem. I have regular instances of the CPU meter going > 90% although the general level seems acceptable. This only happens while I’m playing but I don’t do anything extraordinary that would make the behaviour explainable. When GP runs on the Behringer ASIO driver, this will just cause slight dropouts and artifacts. On ASIO4ALL on the other hand (which I would generally prefer due to the lower CPU load I get on average) there are these freezes which sometimes caused the driver to crash so that I had to restart GP altogether.
Any ideas how to fix this or at least to diagnose the cause of the problem?
What are your system specs?
I’d also try with a different (better) audio interface. I’m not sure that ASIO4ALL can handle ultra heavy load without freezing.
Asio4all, under the hood, uses windows’ normal sound processing (mme/maybe wasapi). Problem with this is that windows’ own sounds (arriving device, email, whatever) also uses this, and depending whether the ‘exclusive’ setting is set, only one client at a time may use it. You can change this using the sound control (at least in the older control panel). Another way to control this is by changing the default device of Windows.
It is not necessarily the cause of your problems, but it doesn’t hurt to check…
Quote:
FlexASIO is a universal ASIO driver, meaning that it is not tied to specific audio hardware. Other examples of universal ASIO drivers include ASIO4ALL, ASIO2KS, ASIO2WASAPI.
Universal ASIO drivers use hardware-agnostic audio interfaces provided by the operating system to produce and consume sound. The typical use case for such a driver is to make ASIO usable with audio hardware that doesn’t come with its own ASIO drivers, or where the bundled ASIO drivers don’t provide the desired functionality.
While ASIO4ALL and ASIO2KS use a low-level Windows audio API known as Kernel Streaming (also called “DirectKS”, “WDM-KS”) to operate, and ASIO2WASAPI uses WASAPI (in exclusive mode only), FlexASIO differentiates itself by using an intermediate library called PortAudio that itself supports a large number of operating system sound APIs, which includes Kernel Streaming and WASAPI (in shared and exclusive mode), but also the more mundane APIs MME and DirectSound. Thus FlexASIO can be used to interface with any sound API available on a Windows system. For more information, see the backends documentation.
Among other things, this makes it possible to emulate a typical Windows application that opens an audio device in shared mode. This means other applications can use the same audio devices at the same time, with the Windows audio engine mixing the various audio streams. Other universal ASIO drivers do not offer this functionality as they always open audio devices in exclusive mode.
Endquote.
Generally speaking, manufacturers that provide audio drivers for their hardware do so to improve their hardware’s performance over what could be achieved with hardware agnostic drivers, and in many cases, hardware specific drivers enable functionality that may be unique to the hardware. Using the manufacturer’s drivers is usually the first choice and recommendation, but the million dollar question is whether the manufacturer keeps up with OS changes for their older gear. Behringer is one of the companies that do to keep their drivers up to date in my experience, and I personally use a Behringer 1820 for many hours every day of the week and it has been flawless with GP and Windows 11 in general. It also performs better with the manufacturer’s drivers than several hardware agnostic drivers that I have tested. The other issue with hardware agnostic drivers is they can be a challenge to configure correctly. In the case of FlexAsio you usually need a third party tool to customize the configuration file. Since the problem seems to be experienced when using GP, I will close by pointing out that numerous plugins - instruments, effects and other audio processing plugins - can have enormous changes in resource demands that can easily overwhelm your processing capacity if you don’t know what’s going on. Sample library size isn’t the only thing, many instruments can scale up to hundreds of voices depending on the preset and what you are playing, other plugins just require a lot more processing time and aren’t recommended for live use (depending on what you are doing with it!). Hope this general info helps.
Here are a few suggestions to help address the issue:
Buffer size adjustment: Try increasing the buffer size in ASIO4ALL settings. A larger buffer size can help alleviate the CPU load and reduce the likelihood of dropouts or freezes. However, keep in mind that increasing the buffer size introduces additional latency, so you’ll need to find a balance that works for your needs.
CPU optimization: Make sure your laptop is optimized for audio performance. Close any unnecessary background processes or applications that could be consuming system resources. You can also check the task manager to identify any CPU-intensive processes that might be causing the freezes.
Wi-Fi adapter interference: Wi-Fi adapters can sometimes cause interference with audio interfaces, resulting in performance issues. To minimize this, try the following:a. Update drivers: Ensure that you have the latest drivers for both your Wi-Fi adapter and your U-Phoria 1820 interface. Check the manufacturers’ websites for any available updates.b. USB port selection: Experiment with connecting your U-Phoria 1820 interface to different USB ports on your laptop. Some USB ports may have better compatibility or provide more stable performance.c. USB power management: Disable USB power saving features in your computer’s power management settings. This can prevent power fluctuations that might affect the stability of the audio interface.d. Separate USB hub: Consider using a separate powered USB hub for your U-Phoria 1820 interface. This can help isolate it from other USB devices and potentially reduce interference.
Latency compensation: In GP, check if there are any settings related to latency compensation or delay compensation. Adjusting these settings can help compensate for the latency introduced by the audio interface, reducing the likelihood of timing issues with MIDI playback.
Contact support: If the issue persists, it might be beneficial to reach out to the support teams for GP, ASIO4ALL, and Behringer. They may have specific insights or troubleshooting steps tailored to your hardware and software setup.
I’m using a Windows 10 laptop with an i7-1195G7 and 16GB DDR4-3200. The interface is a Behringer U-Phoria UMC1820.
Well, I’ve had these spikes in CPU load from GP for a while regardless of the ASIO driver and I can’t figure out where they are coming from. I just thought that a driver that causes a lower average CPU load will cause less issues in comparison but that didn’t turn out to be true.
I will observe the issue, the network/wifi theory doesn’t seem to hold anyway.
Okay, I have similar problems with the Focusrite. However, I think I found the rather simple reason for the performance issues: I use another power adapter at home with my laptop and although the laptop says it is connected I think the power supply isn’t sufficient. I also do the same thing with another laptop where I render 3d scenes and I was surprised to see that without the original power supply the 3d chip runs really slow although the laptop doesn’t report that it hasn’t enough power.
I know this is really naive since it’s common knowledge that micro chips performance suffers from insufficient power supply but I didn’t quite make that connection when I was focussed on the application on screen
The original power adapter sits in my rehearsal room and there I haven’t had any issues. So maybe it’s as simple as that.
