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.
This section describes advanced usage methods. You need to understand VAC principles and simple usage rules before attempting to use advanced features.
VAC implements all three PortCls port/miniport interfaces: WaveCyclic, WavePci and WaveRT. In general, WaveCyclic is most simple and reliable, WaveRT is newest and most efficient, and WavePci has less latency than WaveCyclic.
These internal interface types affect not only internal communications between VAC and PortCls modules and their efficiency. WaveCyclic and WavePci both implement "old", "standard" or "legacy" KS streaming protocol between KS filter and KS client, while WaveRT implements "RT Audio", "looped" or "realtime" streaming protocol.
Port/miniport types can be chosen in VAC Control Panel, for each cable side independently. Driver restart is required for port type changes to take effect. So carefully watch for two-letter abbreviations, "WC", "WP" and "WR" at the right that indicate actually used port/miniport types.
In Vista and later, WaveRT port/miniport are fully supported by PortCls and RT Audio protocol is fully supported by System Audio Engine. However, RT Audio may not be supported by some audio applications offering "KS interface support". If an application cannot access Virtual Cable pins set to WaveRT mode, try to switch the appropriate cable side to WavePci or WaveCyclic.
Vice versa, some new audio applications may support only RT Audio protocol so you might need to use WaveRT interface for the appropriate cable side.
In general, use the following rules to choose PortCls interfaces:
Capture (recording) and render (playback) cable sides function independently. So you can choose PortCls interfaces and KS protocols for each side separately.
As a KS filter, VAC driver presents a pair of render and capture pins for each cable. Using these pins, Windows audio subsystem builds higher-level audio layers (see Audio layering issues). So, each Virtual Cable presents at least three audio interfaces: WDM/KS, DirectSound and MME (Wave), with a pair of recording/playback endpoints in each layer. In Windows 6.x, there will be a fourth interface, WASAPI.
The following list shows audio interfaces in the order of decreasing efficiency:
To get higher performance and less latency, use the lowest level interface type. To get higher compatibility and less problems, use the highest level interface type.
Using WDM/KS or WASAPI in the exclusive mode, keep in mind that they does not support pin instance sharing. More than one connection to a specific pin is available only if the driver supports multiple pin instances. VAC supports them but not all other audio drivers do. Additionally, the system may refuse to use the pin even if there are available instances.
Using WDM/KS interface, please note that it contains a huge set of features (properties) but some audio drivers, especially third-party ones, are tested only with a limited set of them. Some properties are not documented well so driver developers may not be able to meet all the requirements. Incorrect driver behavior may cause application malfunction or even system crash. Trying a new application, new audio device or new driver version, first test them a little in a minimal environment, prior to performing an important work.
Since Windows 6.x+, DirectSound hardware acceleration is not supported.
In Windows 5.x, VAC can be used via the DirectSound interface much more effectively if its hardware acceleration feature is utilized. To enable Windows to utilize it, you must adjust the hardware acceleration level for the VAC device.
Due to audio layering specifics, audio applications have no full control over audio formats actually used by devices for playback or recording, except for exclusive mode access. In Windows 5.x, recording operation always requests a specified format from the driver, but playback operations in Windows 5.x try to request a most wide format supported by the device for System Audio Engine.
For example, if a DirectSound application requests playback at 48000/24/2, DirectSound subsystem first requests 44100/16/2 from System Audio Engine. If a Virtual Cable is free and this format is within the cable format range, 44100/16/2 will be chosen for the cable format. A second render stream will be created with 48000/24/2 but the cable format cannot be changed when a cable is used. Therefore, VAC will perform a format conversion from 48000/24/2 to 44100/16/2 and signal quality will degrade. To minimize format conversion, you could limit a cable format, or a stream format, or both of them.
Cable format limiting is useful to specify most convenient format range for both cable sides. For example, if you want to use 48000/16/2 at one side and 44100/24/2 at another side, you could set cable format range to 44100-48000/16-24/2-2. It prevents the cable format from locking at low sampling rate and/or bitness due to implicit pin instance allocation for System Audio Engine.
By default, cable format range is restricted to very common range for better compatibility. If you want to use wider range, you can extend the format range using the VAC Control Panel.
DirectSound and MME subsystems often can try some consecutive formats if the driver does not allow them to use their preferred format parameters. A driver cannot suggest to higher-level layers to use particular parameters but it can reject some formats and allow some others. So you could use various stream format limiting modes:
Driver range (formerly "None") - there is no stream format limiting over the common driver features. So a new stream can be created using any format supported by the driver. A format conversion will be performed in most cases.
Cable range (default) - a new stream can be created only if its format is inside the cable format range. A format conversion is performed in some cases.
Cable format - a new stream can be created only if its format exactly matches the current cable format. If a cable is free, the "cable range" mode is used for a first stream (see format selection rules for details). Therefore, no format conversions are performed because all cable streams have the same format. This mode is similar to previous (2.x, 3.x, 4.00 betas) versions behavior.
As an extreme case, you can set the same lower and upper ranges for each cable format parameter and specify stream format limiting mode to the "cable format". Therefore, only a particular format (for example, 96000/24/2) will be allowed for client streams. If both side clients are able to choose such format, no conversion will be performed. All audio data will be transferred through the cable unchanged, with no quality loss.
But don't forget that layered scheme prevents applications from having full control over their audio activity. Some implicit format conversion may occur in System Audio Engine and there is no way to easily check it.
VAC supports format conversion. But due to mixing purposes, VAC cannot directly convert from a playback client's format to a recording client's format. Instead, VAC first converts data from various playback client formats to the cable format, then mixes client data using the cable format. Finally, VAC converts mixed data from the cable format to various recording client formats.
The cable format parameters are selected when a first playback or recording client connects to a given Virtual Cable. Sampling rate, bits per sample and number of channels are chosen from the cable format range to as close as possible to client's format parameters.
For example, if a client requests 44100/16/2 and the cable format range is 22050-48000/8-32/1-8, cable format is set to 44100/16/2 (equal to client's format). If cable format range limits sampling rate to 22050-32000, cable sampling rate will be set to 32000 (the highest possible value). If it is limited to 48000-96000, resulting value will be 48000 (the lowest possible value).
If you don't know which format is used by a particular application for playback or recording , run VAC Control Panel. It shows current cable formats for each cable.
For multichannel (4.1, 5.1, 7.1 etc.) formats, don't forget to adjust default endpoint formats for shared-mode access (Windows 6.x+) or speaker configuration (Windows 5.x).
If cable channel mixing is enabled and cable/client formats have different number of channels, only typical channel conversion schemes for 1, 2, 4, 6 and 8 channels are implemented. In other combinations, all source channels are mixed together and then distributed to all destination channels.
To remap channels, extract particular channels from a stream or add them, use channel scatter/gather feature.
Try to minimize format conversion chances. A conversion is performed by the main CPU and takes significant CPU resources, so it may noticeably slow your applications. When used by many clients at a same time, it may even hang your system because the conversion is performed by kernel-mode threads that usually have higher priority than most system and user application's threads.
VAC supports volume control (attenuation or boosting). For each playback or recording stream, volume and pan can be controlled via appropriate interface methods. For the entire cable, a main volume, pan and mute can be controlled, either via an audio mixer interface or the Windows Audio Mixer Control application.
To use cable volume control features, you must enable Volume Control in the cable configuration parameters.
Volume control limits are -40..+12 dB (from attenuation by 100 times to amplification by 4 times of the voltage level).
To control cable volume parameters, use Windows Volume/Mixer Control tool:
VAC supports both recording (source) and playback (destination) volume controls. But among recording volume controls, only selected source line's controls affect cable volume.
Like format conversion, volume control takes some CPU resources and affects sound quality. Use it only when really needed.
If you need to transmit an audio stream from a Virtual Cable endpoint to another audio endpoint or vice versa, you may encounter clock rate difference problems. In such case, check if the application that performs the transfer, supports clock control feature of VAC driver.
If you use Audio Repeater (either MME or KS versions), use turn VAC clock control on.
If the application that uses a Virtual Cable together with another audio device, does not support VAC client clock control, you can try to adjust cable clock permanently, changing cable's clock correction ratio until cable's internal clock speed becomes closest to another device's clock.
Mixing of output streams is implemented with a saturation (clipping). If the amplitude value exceeds a maximal range defined by the sample bitness, it is clipped to the maximal value.
VAC uses relatively simple linear resampling algorithm and does not use dithering or other advanced smoothing features. Therefore, conversion results may sound worse than an original signal. To prevent quality degradation, you need to pay attention to a format matching. Ideally, all three formats (playback client's format, cable format and recording client's format) should be the same.
If all formats are equal and cable volume control is disabled, VAC performs no conversion, all samples are copied directly, and only mixing is performed if there are more than one playback clients. In such case, no quality degradation occurs (a BitPerfect transfer is performed). If you play a WAV file to the playback side and simultaneously record data from the recording side, recorded data will be equal to played data, except for possible leading and/or trailing silence.
But such perfect results can be achieved only if all used formats are the same, volume control is disabled and audio data path is clearly understandable. In Windows 6.x+, it is hard to clearly understand audio data path unless WDM/KS interface is used.
Use packet mode only when really needed
Packet mode can significantly improve stream reliability when you want to be sure that there is no buffering issues (clicks, pops, gaps etc.) at all. But this mode also has a drawback: when there is not enough buffering time margin, the driver may detect false overflows/underflows thet don't actually occur. When the driver reports such overflow/underflow, the client may decide to resynchronize buffers; this procedure leads to the appearance of a sound artifact. Without packet mode, buffering artifacts may be completely or almost inaudible.
Therefore, enable packet mode for one or both cable sides only to increase data reliability. Without packet mode, there are usually fewer artifacts in a buffer shortage situation.
In Windows 6.x+, you can explicitly choose a default format for shared mode operations, so you may ignore the following.
Windows 5.x audio subsystem in shared mode, due to layering issues, propagates only recording audio format on a first device connection, when a common pin instance is created for System Audio Engine. If a first connection issued to a Virtual Cable endpoint is a playback request, shared format selection will be more complex and less predictable. So in Windows 5.x, it is better to start a recording operation with Virtual Cable before you start a playback operation on the same cable. It will fix the cable format and further playback operations will not change it.
An "operation" stands for an actual recording/playback process, not running an application. Some applications have a special button and/or menu command to start an operation. But some other applications can start an operation when they want. For example, Skype starts them when a peer connection is established.
To watch the cable format evolutions, use the VAC Control Panel.
System Audio Engine, due to its bug, cannot create KS stream if there are active instances of the pin being instantiated. So if you start a KS recording or playback client before starting higher-level clients (MME, WASAPI etc.), System Audio Engine will not create its own pin instance, failing a playback/recording request to the appropriate higher-level client.
So if you mix KS and higher-level interface clients with the same Virtual Cable, start at least one of playback and/or recording higher-level interface client first, allowing System Audio Engine to allocate first pin instance of the appropriate (playback and/or recording) cable side. Then you can start as many KS clients as set in maximum number of pin instances.
Starting from 4.70, VAC driver is cheating System Audio Engine by default, so you can start KS clients first. But don't forget that the first client sets cable format. If the default format is different, format conversion will be performed.
To properly transfer multichannel audio data, you must configure the Speaker Configuration for a particular Virtual Cable. Virtual Cable's Speaker Configuration must match the channel distribution of the audio format. To adjust Speaker Configuration, do the following:
Starting from Windows 6.x+, the Configure button is not available for cables with disabled speaker-type pins (default setting). You can enable speaker pin type for some cables but all these cables will have the same "Speakers" playback endpoint name so it would be hard to distinguish between them.
Mixing cable client streams to cable sound and distributing cable sound among client streams, VAC processes audio channels by three possible ways:
Scatter/gather modes are used if the Channel Mixing is disabled for the cable. Internal cable mixing buffer in the cable format always has all channels placed sequentially. So scattering can be performed either from a playback stream having less channels than in cable format, or to a recording stream having more channels than in cable format. Vice versa, gathering can be performed either from a playback stream having more channels than in cable format, or to a recording stream having less channels than in cable format.
For example, the stream has stereo format (two channels) and mask 0x410 (BL+SR) while cable format has 7.1 format (eight channels). If the stream is a playback one, two stream channels will be scattered to eight cable channels: left stream channel will be mixed to BL cable channel, and right stream channel will be mixed to SR cable channel. If the stream is a recording one, two stream channels will be gathered from eight cable channels: left stream channel will be taken from BL cable channel, and right stream channel will be taken from SR cable channel.
In other words, there can be two data transfer paths: from audio application (source) to Virtual Cable (destination), or from Virtual Cable (source) to audio application (destination). If source stream has less channels than destination stream, scattering occurs. If source stream has more channels than destination stream, gathering occurs.
Please note that channel reordering is not supported. Scattered/gathered channels are always packed in the same order as source channels.
Scattering/gathering is performed only if cable and stream channel masks are overlapped (bitwise AND is non-zero). Otherwise, direct transfer is performed (first source channel copied to first destination channel and so on).
Most applications don't allow to explicitly specify channel distribution masks; instead, they assign a standard mask based on the number of channels. To use scatter/gather feature, you need to use KS version of Audio Repeater or develop your own application accessing Virtual Cable pins via WDM/KS interface.
You can watch how channels are repositioned using cable and stream signal level indicators.
See the example demonstrating scatter/gather feature usage.
For performance and stability reasons, VAC uses its own stream data processing engine in WavePci mode, partially bypassing the code provided by the standard Windows PortCls driver. But VAC internal data processing engine does not cover all possible KS features so there may be some problems with it. In case of such problems, you can disable internal VAC engine and use PortCls' one. In such case, you may need to restrict system threads affinity to partially avoid known PortCls problems.
WaveRT and WaveCyclic port/miniports do not require such workaround.
Starting from 4.70, VAC driver doesn't report its actual pin instance counts to System Audio Engine (AudioDG) to avoid failures in creating a high-level strem due to Windows bug. If the pin instance count request (KSPROPERTY_PIN_CINSTANCES) comes from AudioDG, VAC driver now reports zero in CurrentCount, making the Engine think that there is no active pin instances (streams) associated with the filter.
This workaround allows to start one or more KS clients before starting a high-level (WASAPI, DirectSound, MME etc.) client.
If for some reason you need to restore the standard behavior of the driver, enable reporting of instance counts for the appropriate cable side, and restart the driver to propagate the change.
Before increasing number of cables over 5-10, please read about system limitation and overhead issues.
To get rid of format support problems caused by Windows bugs, you can use format attribute policies. By default, VAC driver supports format attributes and signal processing modes only for Windows 8.1 and later systems, and only for WaveRT port/miniport types. In some strange cases, explicit policy can be defined.
Format attribute policies can be configured globally or per-cable. Per-cable policy other than default takes precedence over any global policy. If default per-cable policy (or no policy) is specified, global policy is used. If a non-default policy is applied to the cable, it is used for both capture and render sides. If default policy is applied, each side chooses its own actual policy.
VAC driver must be restarted to change format attribute policies. Actual policies chosen for cable sides are shown in driver event log.