Frequently Asked Questions

Definitely, no. There is no way to ensure an absolutely reliable and stable streaming in Windows because Windows is not a real-time operating system. In most cases, a hardware-assisted streaming, when you play and/or record a stream to/from a hardware audio adapter, is quite stable because all audio data processing is performed by a separate hardware device, not by the main CPU, and redundant buffering is used. Since VAC represents virtual devices that have no dedicated hardware support, it has to compete with other user threads and system components in main CPU resources usage.

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 (10 or 1 ms), the probability significantly drops. Only enough buffering can prevent arbitrary data loss. 

Therefore, some special measures must be taken to achieve more reliable and stable streaming. Please learn about audio layering issues, advanced usage rules, HowTo and Troubleshooting sections.

No, it doesn't. Once purchased a license, you will get full version package and need just to install it instead of trial version.

Definitely, no. 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.

Definitely, 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.

No, VAC operates only locally. But you can use VAC together with an network audio software like Skype to route audio signals over a network. Please note that audio quality will depend on network software behavior.

Definitely, no. It only means VAC driver is loaded and a signal is routed from a Virtual Cable device to the speakers/headphones. To make sure VAC works for you, please build a proper application chain that routes a useful signal (with the "trial" voice mixed).

In other words, if trial version works exactly as you need, successfully routing your audio data, and you only want to get rid of the "trial" voice, then you can consider that VAC correctly works for you.

Full version features differ from a trial ones only by a maximal number of cables. Full version also does not add a female voice reminder to the signal. See the trial version limitations for details. Sound quality is the same in trial and full version, no quality degradation measures are taken in trial version.

Therefore, trial version has all the features of full version and can do anything that full version can do except number of cables. If three cables are enough for your task but you cannot get the trial working, it means you are doing something wrong or VAC is not intended to your task at all.

If you have successfully applied trial version to your configuration but your task simply requires more than three cables, full version will work for you. But please note that using many cables may introduce some problems.

You need as many cables as many independent audio signals you want to pass between applications:

• To pass a single audio signal from one application to another, you need a single cable.
• To mix three signals from three applications and pass a single combined signal to fourth application, you still need a single cable.
• To pass two independent signals, you need two cables.
• To mix two signals into a single combined signal and mix three other signals into a separate combined signal, you still need two cables, and so on.

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.

Technically, it would be simpler to enable all cables by default and avoid additional steps required to do it. But each cable, regardless of its actual presence, needs to be installed as a system subdevice and needs some records in system registry. In some cases, Windows needs to query not only subdevices actually present but all installed but currently unavailable subdevices. If all 256 cables are installed, Windows 6.x may require up to one minute to open audio device applet when you right-click the speaker icon in the taskbar and select "Playback devices" or "Recording devices".

Therefore, usual number of cables is limited to 16 to avoid unneeded delays. In rare cases when more cables are needed, it is easy to replace the .inf file and reinstall 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 WDM/KS, directly or via an ASIO wrapper like ASIO4ALL or ASIO2KS. Shared-mode streaming methods have lowest performance and highest latency.

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.

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.

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. But in Windows 5.x, you can use different user accounts to map default devices differently for different applications.

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.

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".

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:

• T8300 (2 cores, 2.4 GHz), Q9550 (four cores, 2.8 GHz) or 3610QM (four cores, 2.3 GHz) CPU
• Single Virtual Cable device configured for 5 ms per event, no volume control
• 32 Audio Repeater KS instances (Virtual Cable 1 to Virtual Cable 1, 44100/16/2, 20 ms per buffer, 4 buffers, no format conversion)

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 Audio Repeater MME instances (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 dozen percent of CPU resources. The higher are sampling rate and number of channels, the more CPU resources are taken 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.

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..3) for some cables, try to increase it at least to 5..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 Windows 6.x, AudioDG process hosts almost all audio processing in the system (basic audio interface support, System Audio Engine, 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.

Definitely, no. VAC simulates a simple electric cable, it cannot synthesize a 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.