The place and role of VAC among applications and devices

If you need a means of redirecting sounds between applications and devices, you will find a lot of messages on the network that this is often done using Virtual Audio Cable (VAC). There are quite a lot of recipes for using VAC, they are easy to find on the web, but most users usually rely on intuition.

Having decided to try the product, you go to the website, download the trial version and install it. As usual, you expect that a shortcut to a new application will appear on the desktop, which you can launch, and then act intuitively. But there is nothing new on the desktop.

Then you open the Start menu, find the Virtual Audio Cable folder there, which really has several applications (VAC Control Panel, Audio Repeater, Audio Repeater KS). You launch them, but still don't understand how to use all this, for example, to send sounds from a file to Skype or Zoom. None of the listed applications offers anything like this. You begin to suspect that something is wrong with VAC. And you're right.

The fact is that most applications are "self-sufficient" - they do all the work themselves, and generally do not interact with other applications. Even if applications share common file formats (RTF, ZIP, WAV, etc.), they usually work only with files. For any of these applications to work, it is not required that any other application using the same file format is active (running), or at least installed. In such a situation, indeed, you can simply launch the application and understand it intuitively using hints.

On the contrary, VAC is not a traditional, self-contained application - it serves as a means of communication between other applications. When installing VAC, a special service (virtual device driver) is created in the system and provides applications with the means for such communication. But the system does not provide the ability to connect arbitrary applications forcibly. Each of them must be configured to use VAC.

This is similar to a group chat, a messenger channel, a group in a social network, and similar structures. In order for two people to communicate with each other, they both need to connect to the same "communication channel". The channel cannot connect to them by itself, or force them to connect to itself.

For Windows applications, such audio transmission channels are the endpoints (logical ports) of audio devices. Historically, it has been done so that each endpoint can serve either as a transmitter of sound outside (playback), or its receiver from outside (recording). If an application wants to play and record audio at the same time, it must connect to two endpoints at once.

VAC creates virtual (non-hardware-related) audio devices in the operating system - virtual cables. Each virtual cable has two endpoints at its "ends" - playback and recording, respectively. The sound sent by any application to the playback endpoint of one of the cables gets into VAC driver. The driver directs it to the recording endpoint of the same cable, from where any other application can receive the sound. And if one application simultaneously connects both endpoints of the cable, and sends sound to the playback one, then this sound will be returned to it from the recording endpoint.

The same can be obtained by connecting the line input and output of the computer with a sound cable. But only one such channel can be created on one audio adapter, and the sound will lose quality, passing sequentially through the DAC, ADC, amplifiers and filters.

Thus, in order to send sound from an existing MP3 file to Skype, you first need to make sure that the sound played from the file goes to a virtual cable, and then Skype receives sound from this cable instead of a microphone. To do this, it is enough to launch any sound player that allows you to specify a playback endpoint (WinAMP, Foobar2000, AIMP, etc.), and specify a virtual cable endpoint for it (for example, Line 1). And in Skype, instead of a microphone, you need to specify the opposite end of the cable (Line 1 or Mic 1). By starting the playback, you will see that the sound is coming to Skype, and your interlocutor on the other side hears it.

But at the same time, you will find that the interlocutor has stopped hearing you when you speak into the microphone. This happened because all sound transmission channels are independent, and the sounds in them do not mix. In order for the interlocutor to hear you, it is enough to launch Audio Repeater, select a microphone as a sound receiver in it, and a virtual cable (Line 1) as a transmitter. As soon as you press Start in the Audio Repeater, it will receive the sound of your voice from the microphone, and immediately send it to the virtual cable. Then VAC driver will transmit this sound to the other end of the cable, where Skype will receive it. When the sounds of your voice and the sounds of the MP3 file come into the cable at the same time, VAC driver mixes them together.

Now you can start a sound recording application (Audacity, Wavosaur or any other), specify Line 1 as a recording source, and it will record the sound from the MP3 file being played, with your voice superimposed on it, as your Skype interlocutor hears it all. But his voice will not be recorded, as it is still transmitted on a separate channel that does not mix with others. To record it as well, you will have to complicate the setup.

You will say that the setup is already complicated even for such a simple example as sending audio to Skype from a microphone and from a file at the same time, and you will be partly right. The fact is that VAC can be used with absolutely any Windows applications, in any quantities and in the most bizarre combinations. The relative complexity of the setup is an inevitable price to pay for the versatility of VAC. There are more convenient tools for special cases, but their functionality is limited.

You can also say that VAC could configure the applications itself according to a given scenario, rather than requiring you to do it manually. Alas, this practice is unacceptable.

Each application in Windows is an independent entity, and stores its settings in a convenient form for it. There is no single format for storing settings, nor a way to ensure their integrity without the participation of the application. Therefore, an attempt by one application to change the settings of another will always be a risky activity, fraught with damage to settings and application failures. Even if such attempts are successful, such actions may rightly be considered malicious. The laws of some countries prohibit such interference in the operation of applications, even if it is initiated by the user - the consent of the copyright holder is also required.

Imagine that the phone company, without warning you, changes your phone number. Or, without asking, you are subscribed to group chats, included in groups, or even just include your address in the mailing list. An application whose settings have been changed without his knowledge may be in the same position.

So that applications do not need to interfere with each other's settings, there are many standard communication tools and protocols in the operating system: files, various messages, pipes, shared memory, etc. System means of interacting with devices, including audio, are also standardized. Therefore, specifying specific audio devices for each application is a standard, reliable and secure way to establish communication.