Virtual Audio Cable (VAC)
25+ years of experience. Connects audio apps together since 1998.
Virtual Audio Cable (VAC)
25+ years of experience. Connects audio apps together since 1998.
What ... (some term) stands for?
If you see an unknown term in VAC Control Panel or Audio Repeater interface, or in this user manual, try to enter it on the "Search" tab of the local manual/help database (the .chm file). If some manual pages displayed on the right side, read the appropriate topics.
How to use VAC for/with ... (some task/app)?
Try to select some keywords describing the task, or app name, and enter them on the "Search" tab. Maybe there is a recipe.
I am evaluating Trial version and I hear the repeating "trial" voice. Does it mean that everything is working correctly?
No, it doesn't. It only means that Trial version of VAC driver is loaded and a signal is somehow transmitted from the recording side of the virtual cable to the speakers/headphones. To make sure VAC works for you, please build a proper signal routing chain that transfers a useful signal (together with the "trial" voice mixed if Trial version is used).
In other words, if Trial version works exactly as you need, successfully routing your audio signals, and the only undesired effect is the periodic voice reminder, then you can consider that VAC correctly works for you.
If you don't know where to start, try to start from the beginning.
Why some fields in VAC Control Panel are grayed out?
It means that this product version is feature-limited.
Can VAC capture/intercept all sounds in the system?
No, it can't. VAC driver never affects audio streaming unless explicitly requested. If an application wants to play sounds to or record from a specific audio device, VAC doesn't prevent it. To capture/intercept sounds coming from/to application(s), you need to establish an appropriate routing scenario by specifying source/destination audio endpoints for the application(s), assigning some endpoints as default ones, etc.
Can VAC replace a hardware device?
VAC could replace a hardware audio device only if the device does not interact with the real world. For example, if it is used only as a loopback tool: the output is directly connected to the input, so all sounds played to the speakers/headphone endpoint, can be recorded from the microphone/line endpoint.
If the hardware device is used for its intended purpose, to play sounds or record them from the real world, VAC can only expand the connectivity to the software (for example, to mix particular sounds and play the result, but send other sounds over the network).
Since VAC does not interact with the real world, it cannot replace a hardware device that does this.
Can VAC improve sound quality?
No, it can't. VAC just passes audio signals, possibly mixing them and/or changing their volume level. It performs no advanced signal processing.
VAC supports high sampling rate and bitness that allow to represent audio signals with highest possible quality, but this just allows to keep the quality of the existing signal, not to improve it. If an application produces a high-quality signal (for example, in format 96000/24), VAC can pass it without quality loss. But if the signal is then played to a hardware device that supports only 48000 samples per second, or 16 bits per sample, output signal quality will deteriorate.
What audio format parameters are necessary for high-quality sound?
Most common industrial standards used since the late 90s, assume "96/24 format": 96000 samples per second, 24-bits per sample for PCM encoding. Most experts believe that such encoding is quite sufficient to preserve all the nuances of the audio signal..
But many enthusiasts believe that higher sampling rates and/or bitnesses may improve sound quality, and seek to use 192000 or even 384000 samples per second with 32-bit samples. There is no practical evidence that human ear can distinguish them from 96/24. Moreover, in most correctly arranged experiments, the vast majority of listeners were unable to distinguish higher sampling rates and/or bitnesses from 44.1/16 (CD format) or 48/16 (DVD format). Only some experts can do this, but not confident enough.
Many recordings distributed in "high-resolution" formats are actually just upsamped copied of traditional ones, but listeners who believe in their high quality often find them more pleasing to the ear.
Therefore, it makes sense for everyone to determine the capabilities of their hearing by comparing recordings from reliable sources, preferably blindly, in order to reduce the influence of beliefs.
If you want to make a high-quality recording that will suit any reasonable listener, you can use 96/24 format. But this will only be justified if the best microphones, amplifiers, DACs/ADCs, digital processing algorithms and other components are used in recording, processing and playback. If you are not an audio professional, you have very little chance of getting a result superior to typical 48/16.
Does VAC ensure absolutely reliable and stable streaming?
Unfortunately, no. There is no way to ensure absolutely reliable and stable streaming in Windows because Windows is not a real-time operating system, and there are some objective reasons for stream instability. Additionally, software-only streaming is less stable than hardware-assisted one.
Therefore, some special measures must be taken to achieve more reliable and stable streaming. Please learn about system performance checking and tuning, audio layering issues, advanced usage rules, HowTo and Troubleshooting sections.
If the buffering problems occur due to clock rate difference effects, use cable clock correctionl features. Currently, only Audio Repeater application supports dynamic cable clock adjustment.
Why VAC sometimes produces glitches, while the hardware devices don't?
When an application plays to or records from a hardware device, only the software part (the application itself, intermediate libraries, if any, system audio components and the device driver) are experiencing unpredictable delays that disrupt stream stability. The audio hardware, being physically separated from the main CPU, works independently, so it is much more stable and usually can compensate some delays.
On the contrary, a virtual device driver like VAC serves virtual devices having no dedicated hardware support, so the driver code is forced to compete with all other applications and system components for CPU resources.
Additionally, when an application plays to or records from a virtual device like VAC, there must be at least one application on the opposite side. Therefore, all these applications and VAC driver, together with all other software components involved, compete with each other and experience unpredictable execution delays. Much more code is involved in data processing, but there is no independent, stable component that could compensate the delays.
In some cases, these delays become longer than even the hardware may compensate. For example, if you run a low-latency (with buffering duration less than 15-20 ms) streaming software using hardware devices only, and produce heavy CPU and/or network load, copy large files to/from external USB devices, use system management features (Fn keys on a laptop, Win-L to lock the workstation and then unlock it back, energy saving functions, etc.), you may notice audio glitches too.
Is VAC better than other virtual audio software solutions?
No solution can be better in everything than any other. VAC is a versatile and powerful tool but, as well as any other particular software product, it cannot provide optimal behavior for everyone without exception. Those who need complexity and manageability may find VAC very useful. However, those who need simple and easily customizable solutions often find it excessively difficult to learn and use.
In addition, different technical solutions are used in different products. Since Windows is not a real-time OS, balancing reliability and efficiency requires compromise solutions that are suitable for most situations, but in some situations may be ineffective or unreliable.
To understand which solution is best suited to you specifically, you need to test different virtual products in specific conditions, on specific tasks. Some users use two or more virtual products at the same time, using each of them where it is most effective and convenient.
Why audio streaming may be unstable?
To maintain a stable audio stream, all hardware and software components involved must work consistently and be in time. If any of the components delays the reaction, the entire stream may fail, producing a glitch (click, pop or gap).
In Windows, there is no guarantee that an application (and even a kernel-mode driver) code will certainly executed within a given period of time. For relatively long periods, like one second, the probability is almost 100%, and even for 100 ms, the probability is very high. So, in general, multi-threading works well. But for short periods (20, 10 or even 1-3 ms), this probability significantly drops. Only enough buffering, used on all data processing layers, can prevent arbitrary data loss. However, by increasing the stability of the stream, long buffers also increase latency.
Unexpected processing delays occur for various reasons:
Unfortunately, due all these features, achieving high stream stability with low latency is a kind of shamanism. Usually, desktop systems are more stable and predictable than laptop/notebook ones, because laptops have much more energy saving features than desktops. In some cases, it is impossible to have a stable streaming together with high network and/or USB throughput, and you have to sacrifice something.
Can reinstalling the software affect the sound quality?
In most cases, reinstallation cannot affect the sound quality. If VAC driver is loaded and high-level endpoints are present, it means that all critical components of the product are installed and accessible. Reinstallation may help only if some product functions are unavailable (no shortcuts in the Start Menu, some files are missing, error messages are displayed by the system and/or applications, etc.).
Therefore, if all product functions are available but sound quality is not good, it is most likely caused by the settings of audio applications, VAC driver, the system itself, or even by the hardware features. If you experience glitches (cracks, pops, static, etc.), please read about stream stability issues. If the streaming is stable but sound quality is getting worse, please check the format conversion issues.
Sometimes it happens that after reinstalling the product, the stability of the streams and/or the sound quality becomes better or worse. In most cases, the changes are not related to the reinstallation itself, but to some associated actions (changing the settings, closing and reopening the applications, restarting system services, restarting the entire system, etc.).
Users usually use reinstallation, as it sometimes helps to fix problems with complex products consisting of many components that require certain settings to interact with each other (for example, registering components in the system, preparing databases, etc.). In a VAC product, the only component that requires registration in the system is the virtual device driver. If it is installed and downloaded, everything else is determined solely by hardware properties and software settings.
Does VAC use registration keys, Internet activation procedure or other technical licensing measures?
No, it doesn't. Once purchased a license, you will get Full version package and need just to install it instead of Lite/Trial version.
I have created several virtual cables but only some of them are visible. Why?
Windows releases starting from Vista use Audio Endpoint Builder service that creates high-level endpoints for low-level pins. On every pin reconfiguration, Endpoint Builder must query the pin for various information and create/modify/delete the appropriate endpoint.
From release to release, Endpoint Builder behavior becomes worse. It issues hundreds of redundant queries to each pin. To prevent high system load, Windows may use a kind of throttling, inserting pauses between sequential queries. System load was reduced but processing time was increased significantly. For typical hardware devices with 1-3 endpoints, the time never exceeds several seconds. But VAC driver exposes four pins for each virtual cable, so the processing may consume 2-3 minutes for 15-20 cables. Creation of 100-150 cables may require up to several hundreds of megabytes of RAM and 15-20 minutes of 100% CPU load. The same effect is occurs if number of cables is significantly decreased.
The order in which cable endpoints appear in the lists, is undefined. For example, "Line 10" may appear immediately, then "Line 2", then "Line 1", and so on.
Can VAC affect features of other audio devices?
No, it can't. VAC implements a fully independent audio device that doesn't directly interact with other devices, either real (hardware) or virtual (software-emulated). So it can't expand capabilities of other devices, enhance their sound quality, fix compatibility issues, or affect their functionality in any other way. For example, VAC can't force two Bluetooth devices to work at the same time if this is not supported by the Bluetooth stack.
Similarly, VAC can't enable "What You Hear" or "Stereo Mix" recording function of a hardware audio device if this feature is not implemented or disabled, although these functions look similar to what VAC does.
"Stereo Mix" and "What You Hear" implement a loopback from an audio endpoint: the primary endpoint is associated with a particular destination (speakers, headphones, external line output, etc.), and its "Stereo Mix" endpoint is just an auxiliary one that returns an "echo" of audio signals played to the primary one. When there is no signal played to the primary endpoint, "Stereo Mix" always returns silence. There is no way to get signals from Stereo Mix endpoint without playing them to the primary one. So Stereo Mix is like an Y-cable that splits the signal and allows to record it back. If audio device performs some signal processing (audio effects, filtering, noise suppression, etc.), the signal recorded from the loopback endpoint will have the same characteristics.
VAC driver implements straight virtual cables. Audio signals played to the playback side of the cable, are directly returned by the recording side. No other routing is performed. VAC driver does not interact with other audio devices. It cannot automatically intercept any audio signal, it can route signals only if cable endpoints are explicitly used in audio path.
If you are using Vista/Win7, there can be a loopback source line in your audio adapter but disabled by default. To check it, right-click on speaker icon in the system tray, select "Recording devices", right-click on any device in the list and select "Show disabled devices". Some additional devices may appear. If there is a device like "Stereo Mix", right-click on it and select "Enable".
You can record sounds from applications and/or system by directing their audio output to some virtual cable device. It can be achieved by selecting virtual cable device in application's audio settings or using virtual cable as a system default device.
Since audio output will go to virtual cable instead of your audio card, you need to monitor the cable to hear the sound.
My audio adapter (soundcard) has analog and digital outputs but I cannot use them in the same time. Can VAC help?
Unfortunately, no. VAC cannot extend limited hardware capabilities. If an audio adapter allows to use its inputs/outputs in the same time and its driver doesn't restrict it, you should be able to use them independently. But some adapters have simplified drivers that allow to use only a single output line. You could look for another driver, maybe it exists. For example, there can be a driver for Windows 5.x suitable for Windows 6.x+ too.
Can VAC route sound between different PC's over the network?
No, VAC operates only locally. But you can use VAC together with a network audio software.
I have tried Trial version but was not satisfied. Will Full version work better?
No, it won't. The Full version has the same features as the Trial one. The Full version only does not add female voice reminder to the signal. Sound quality is the same in both Trial and Full version, no signal quality degradation occurs in Trial version.
If you have successfully applied Trial version to your configuration, the Full version will work for you. If the features of Trial version are not enough for you, the Full version can't offer more features.
If you are dissatisfied with the stability of the Trial version, the Full version will not work better in the same conditions, because the conditions don't allow the software to work reliably. In such case, please check your system for the suitability, and learn about streaming stability guidelines.
How many virtual cables I need to implement my task?
You need as many cables as many independent audio signals you want to pass between applications in certain direction:
Please note that each cable is single-directional. Therefore, if you have two applications capable to produce and receive audio signals at the same time, you need at least two cables to create two-way communication between these applications.
How much is sound latency with VAC?
VAC itself adds almost no latency but actual value is much more dependent from an audio interface used by the application and application's audio buffer configuration than from a virtual cable timing event frequency.
Very good performance and latency can be achieved using exclusive-mode device access (hardware-accelerated DirectSound in Windows 5.x, WASAPI in Windows 6.x+). For even better performance and lower latency, you can use KS protocols, directly or via an ASIO wrapper like ASIO4ALL or ASIO2KS. Shared-mode streaming methods have lowest performance and highest latency, but they are more tolerant to unexpected execution delays.
Typically, latency time is comparable with an audio buffer granularity. For example, if application uses a total buffering time of 500 ms divided into four buffer parts, average application latency time will be 500 / 4 = 125 ms. If a cable is configured to 10 ms per interrupt, cable latency will be no more than 10 ms. In case of using audio interface other than KS, some latency is added by System Audio Engine.
To reduce latency time, first try to decrease application's audio buffer granularity. Some MME applications allow to specify number of audio buffers and a total buffering time; set these values to 50..100 ms per buffer part and 500..1000 ms of total time. DirectSound applications also may allow to specify a minimal buffer fragment size for processing.
You can also try to decrease the number of milliseconds per interrupt for a cable but it may help to decrease latency time by several milliseconds only.
With a well-tuned configuration (hardware, OS and applications), it is possible to reduce latency time down to several milliseconds. Latency less than 1-2 ms is not possible in Windows because a lowest timing interval is 1 ms.
No, it doesn't. To have native ASIO support, additional ASIO driver DLL should be created for VAC kernel-mode driver. This DLL should call the driver to transmit audio data. To interact with VAC driver, such DLL might use either KS protocols or a proprietary one.
But VAC kernel-mode driver efficiently implements KS protocols (both legacy and RT Audio), and there are ready-made ASIO-to-KS wrappers, like ASIO4ALL and ASIO2KS. Such wrappers translate ASIO operations into KS ones. It seems that at least ASIO4ALL is efficient enough, so having a native ASIO implementation would not be better than ASIO-to-KS implementation described above.
If there are accurate measurements showing that ASIO4ALL performance with VAC is noticeably less efficient than direct KS performance, it would be the reason to implement a native ASIO driver for VAC. If you have such data, please share them.
Is ASIO better than standard Windows audio interfaces?
ASIO was introduced in 1990s, when Windows had only MME audio interface for common purposes, and DirectSound was just announced for interactive games. Then there were no standard audio interfaces suitable for low-latency playback, recording and accurate time-stamping, to be used in professional audio environment.
Among most multimedia users, multi-client and format conversion features were much more demanded than low latency and/or BitPerfect transmission. So Microsoft focused on compatibility, while Steinberg and other professional hardware manufacturers focused on precise and low-latency processing. Being simple and reliable, ASIO has become used preferably for multi-channel audio processing and mixing, not for typical multimedia streaming.
In the late 1990s, Microsoft implemented Kernel Streaming, a kernel-mode audio interface that is enough to perform any conceivable ways of audio transmission and/or processing with a negligible overhead. After more than 20 years, KS has been significantly improved, but has not undergone any fundamental changes. Every new feature has been implemented by simply adding new properties and events, without affecting basic principles, performance, or losing backward compatibility.
If KS had been added (and made publicly available) before ASIO, it could have been successfully used for all tasks for which ASIO was developed, and ASIO would not have been necessary. But KS was not only implemented later, but also was unavailable for public for a long time. For many years, no public KS documentation existed. Even now, KS is not fully documented; only Port Class Driver miniports are fully covered by the documentation.
Therefore, ASIO has become industry-standard for audio hardware and software that operates in real time, requires as low latency as possible, and no intermediate signal processing (in general). KS has become common, universal basic Windows interface, on top of which all other interfaces are built.
All other Windows audio interfaces are much less efficient than ASIO and KS. The closest in terms of efficiency is WASAPI in Exclusive Mode.
ASIO and KS have the same efficiency, both communicate with their devices directly, with no intermediate layers. Even more, KS is formally more efficient because it is implemented entirely by a kernel-mode driver, while ASIO is implemented by a user-mode DLL that cannot directly work with hardware, and requires a kernel-mode driver for this, so there are two layers instead of one. But ASIO driver DLL can be a very thin software layer, so the difference in performance is negligible.
Developing a kernel-mode drivers to support both ASIO and KS, it is technically optimal to create a basic KS driver, and implement ASIO on top of KS, like ASIO4ALL or ASIO2KS do. But it so happened that most hardware vendors that provide KS drivers together with ASIO ones, create separate kernel-mode KS driver modules, or implement proprietary protocols for ASIO, separately from the KS protocols. The reason for this is unclear. Perhaps this is because a highly efficient KS protocol is more difficult to implement than a highly efficient proprietary one, so a simplest miniport driver is being created, being enough to implement the minimal KS requirements.
If both ASIO and KS drivers exist for the same hardware, and both are implemented correctly, with the maximum possible efficiency, there is no difference which interface to use. Both will ensure the same efficiency, latency and precision. But in practice, pure ASIO drivers are implemented more carefully and correct, so they usually work better.
Since ASIO is used in most professional audio software, it is often considered "high-tech", "professional", "cool", "best choice", etc. But there is nothing cool or high-tech about ASIO itself. Any interface, being implemented properly, works stably, reliably and precisely. Being implemented improperly, it works poorly.
Therefore, the best interface is the one that is better implemented and better supported by your applications, regardless of its name and/or rating. In practice, most applications intended for real-time signal processing (sound synthesis, guitar or voice effects, multi-channel mixing, studio recording, etc.) work better with ASIO. Most applications intended for audio streaming (playback or recording) work better with standard Windows interfaces.
Can VAC map default audio devices to different cables for different applications?
VAC does not map audio devices. If you assign some virtual cable device as a system default recording and/or playback device, mapping is performed by Windows.
Starting from release 1803 of Win10, the system supports per-application device/endpoint selection: (Windows Sound Settings - App volume and device preferences (Volume mixer in Win11), but this feature may not work properly.
In Windows 5.x, you can use different user accounts to map default devices differently for different applications.
Can VAC be used on a virtual machine (virtual server, VPS/VDS)?
VAC can be used on any Windows machine, regardless of its type. But there are some important issues since VAC is a kernel-mode driver, not a user-mode application. Please read about virtualized environment compatibility issues.
Using VAC in a remote session, please read about remote access compatibility issues.
What are the difference between old and new 5.1 and 7.1 speaker/channel configurations?
Old 5.1 speaker/channel configuration named "5.1" or "5.1 back" contains back speakers/channels (back left and back right). New configuration contains side speakers/channels instead and is named "5.1 surround".
Old 7.1 speaker/channel configuration named "7.1" or "7.1 wide" contains "front left of center" and "front right of center" speakers/channels. New configuration contains left and right side speakers/channels instead and is named "7.1 surround".
Why 24-bit formats are listed twice on the Advanced tab of Audio Properties?
This is because 24-bit samples can be stored either in 24-bit (three-byte) or 32-bit (four-byte) containers. If the maximum sample bitness for the cable is 24, only three-byte containers can be used, and you will see one record for every 24-bit format. But if the maximum bitness is 32, both three-byte and four-byte containers can be used. Since this list doesn't indicate container sizes, you see two identical records for every 24-bit formats. Clicking the Test button, you can see the details in "Current format" column in VAC Control Panel.
Windows doesn't use three-byte or four-byte containers for 8-bit and 16-bit samples, as well as it doesn't use 20-bit and 22-bit samples, so other formats don't have ambiguities.
Why is the microphone icon shown in the tray when only VAC endpoints are used?
Windows shows the microphone icon in the system tray to indicate that an audio recording device is being used (actually performs the recording). This is in order to prevent covert listening and covert recording of conversations.
The system cannot reliably distinguish between the real hardware audio devices and virtual ones, so it indicates the use of any device. , showing such an icon only when a microphone-type endpoint is being used is not enough because a microphone can be connected to the line input as well, or even to a digital input via an adapter. So Windows shows the icon if any audio recording operation is encountered.
But these checks are performed only for the high-level audio interfaces (WASAPI, DirectSound, MME, etc.). On KS and ASIO levels, no checks are performed, so there is a risk of covert listening. The only consolation may be that most audio drivers are single-client, so the process that holds the only available instance of KS pin for covert listening, prevents the System Audio Engine from using this pin for high-level recording. Therefore, if you have not authorized any audio recording operations, but an attempt to record from the audio endpoint fails with an error like "the device is already in use", this may indicate hidden activity in the system that records from the pin using some of low-level audio interfaces.
How much CPU is consumed by VAC?
It depends primarily on number of audio streams processed at the same time, then on CPU type, clock frequency, number of cores, L1/L2 cache sizes, memory type, clock frequency, Windows configuration, audio interface used, application/device interaction algorithm, audio buffers size, number of buffers used, cable event rate, volume control, format conversion options, etc.
For example, the following configuration:
that creates 64 independent audio streams processed by VAC driver, produces about 1% overall CPU load. The load depends mostly on number of streams. For example, 16 cables and 32 Audio Repeater KS instances (Virtual Cable N to Virtual Cable N+1) produce the same 1% load.
32 instances of Audio Repeater MME (500 ms per buffer, 12 buffers) creating 64 streams processed by System Audio Engine and a single stream processed by VAC driver, produce about 5-10% overall CPU load under Windows 7.
With format conversion and/or volume control, each stream processing may consume up to a dozen percent of CPU resources. The higher are sampling rate and number of channels, the more CPU resources are required to process the stream.
Please note that system tracing/debugging features (for example, Driver Verifier) may significantly increase CPU load and decrease stream processing performance and stability.
I see high CPU load when virtual cables are used. Is it normal?
It is normal if there are format differences between a current cable format and recording/playback clients' formats. In such case, format conversion will be performed. It takes a high amount of CPU resources.
Check the number of milliseconds per interrupt parameters for all active cables. If this parameter is very low (1..2) for some cables, try to increase it at least to 3..7.
CPU resources are also used to perform a volume control. If you don't need volume control for a particular cable, it is better to disable it.
In Vista/Win7, I see high CPU load produced by AudioDG process. Is it normal?
In Windows 6.x+, AudioDG process (the System Audio Engine) hosts almost all audio processing in the system (basic audio interface support, local and global audio effects (LFX/GFX), etc.). If you run several audio application that create several audio streams, especially using audio effects, AudioDG may produce significant CPU load, regardless of are virtual cable devices used or not.
Can VAC render my MIDI sequence to a Wave file?
No, it can't. VAC simulates a simple electric cable and transfers encoded digital audio, while a MIDI sequence contains no digital audio at all, it contains only the instructions such as the score. A special interpreter and music synthesizer are required to convert a MIDI sequence to sound. VAC cannot synthesize sound from a MIDI sequence. Although, VAC can help you to record output of some software synthesizers to a Wave file. You also could use a built-in Windows GS software synthesizer that plays synthesized waveform to a system default playback device.