Virtual Audio Cable (VAC)
20+ years of experience. Connects audio apps together since 1998.
Virtual Audio Cable (VAC)
20+ 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 hear the repeating "trial" voice. Does it mean that VAC works correctly?
No, it doesn't. It only means that Trial version of VAC driver is loaded and a signal is somehow transmitted from a Virtual Cable audio endpoint 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 periodical 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.
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.
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 peculiarities, 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.
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.
My audio adapter (soundcard) has no "What You Hear" or "Stereo Mix" recording function. Does VAC implement it?
No, it doesn't. VAC does not interact with other audio devices. It cannot automatically intercept any audio signal, it can route a signal only if a Virtual Cable device is 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:
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 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.
Working remotely, 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 endpoint 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.