Virtual Audio Cables
Imelda Matchett
I finally figured out what was going on.
Came across a blog from Raspberry Pi folks posted early 2021 explaining that they had switched from ALSA sound system to PulseAudio, with a few ALSA plug-ins to maintain some compatibility.
Well, snd-aloop is just not supported - the underlying code is just not there.
The pulseaudio command starts the pulseaudio server.
The PulseAudio Commands (pacmd) each create an output device with the given name,
together with a corresponding input device (the loop back) called [the given name].monitor
Unfortunately this only is visible for me when running Qt audio as the audio system in wFview, and it would appear Qt audio may be why I am getting audio problems. The setup is an RPI over wifi direct to an IC-705. I believe Qt audio may have the wrong buffer size (for wifi udp audio streaming to a 705) when setup by wFview.
I would like to try PortAudio or RT Audio, but the official wFview virtual audio cables no longer work (RPI OS does not support them) and this great system you came up with is only visible to Qt Audio and not PortAudio or RT Audio.
Do you get different behavior if you open a program like wsjt-x, which uses the pulseaudio loopback first, and then open wfview? Some of these programs will set various parameters with the loopback and they often prefer to have their say before wfview is opened.
So here is a wfview log of the RPI connected by ethernet to the home LAN and the 7610 connected by ethernet to the home LAN. wfview was running Qt audio ulaw 1 channel 8 bit for tx and receive at 48000 sample rate. A sample rate of 8000 produced the same result. It would appear from WSJTX decodes that receive audio was fine, but transmit audio had the same problems (TX audio muting/dropouts) exhibited in the mobile configuration (RPI as hotspot and 705 connected over wifi to RPI). In addition, as was the case with wfview 1.58 there was a buzz/distortion on the tx audio. Previously in my testing with 1.6 I did not notice a buzz but that could be just me. see the 7610 all lan/ethernet connected log at
VAC creates a set of virtual audio devices. Each device simulates an audio adapter (usually named a "card") whose output is internally connected to the input, making an audio loopback. If an application plays audio to the output of such device, the sound will not be audible because the signal is looped back to the input. But if another application records from the input, it receives the sound produced by the first app.
Such virtual devices are named Virtual Cables. The term "Virtual Cable" is used only in the description of VAC product, as a placeholder. Actual names of virtual audio devices/endpoints that you will see in applications' menus, are different (for example, "Line 1", "Line 2" etc.).
Each side of any Virtual Cable can be used by several audio apps at the same time. If two or more apps play sounds to the same playback endpoint, these sounds are mixed, and the result is transmitted to the recording side. It two or more apps record from the same endpoint, each app gets a copy of the sound.
There is no quality loss (if no format conversion and/or volume control are involved). If all these conditions are met, audio transfer is bitperfect, suitable for audiophile applications. In well-tuned systems, signal latency is very low.
VAC just performs things what it is intended for: passes audio streams between applications, converting audio formats if necessary. It never guides you to advertising pages, nor pops up busily on the screen, nor installs hidden activities in your system. VAC does only actions that you explicitly demand for.
VAC driver and the supplied applications can only collect and use information directly related to their functionality. For example, VAC driver can query processor functions to optimize performance, request process/thread information to display it in a log, Audio Repeater applications request audio device/endpoint properties, etc. Since they do not work with personal, business, geographical, economic or political data, they do not access such data sources at all.
In Windows I have the program Virtual-Audio-Cable for this and I already read that pulse-audio should serve this functionality, but when I install pulse-audio I don't get this sound-redirecting to work and I get Bugs like my music is stopping when I start Teamspeak or any application with sound output.
So I wan't to have it (if possible) without using pulseaudio (I already removed it from my system).
Jack is certainly the de facto solution for advanced audio routing on Linux. Qjackctl provides a graphical control panel, exposes connections, and allows automatic connections through a virtual patchbay. However, for non-jack-aware apps, you need to use the alsa plugin. [1]
Then send sound to loop_sink and record from loop_source.
Edit: If you want to listen and record at the same time, then you should be able to use module-virtual-sink I think and record from the monitor channel for the virtual sink.
I am broadcasting a game via XFire and it uses the Windows audio device to capture any audio I receive. As I am broadcasting, other users who watch the video stream are communicating with me over Skype, and they hear themselves back within the video stream and it is entirely logical since I am broadcasting the audio I hear.
What I want to do is create another audio device within Windows and redirect (pipe) ONLY the audio input from that game and not the input reveived from Skype. I would then tell XFire to use that newly created "virtual" audio device to broadcast and therefore my partners won't hear themselves back.
To make virtual audio devices that work like virtual audio cables, you can use PulseAudio commands. I make a pair of them to allow two software defined radio apps (eg: WSJT-X or JS8Call) to communicate bidirectionally with each other for testing purposes without needing any hardware:
Tada, from there you will have a virtual audio device. Playing to it as input will result in its output, just as VAC does. However, in pulse audio, it will also show up named as, "Built-in Audio Analog Stereo" - this is probably a bug needing to be fixed in pulse audio. But you'll notice there are two of them, one will be your virtual/loopback device.
If you use PulseAudio, you'll need to use pacmd to create a loopback interface and set its monitor as an input interface to your application: pacmd load-module module-null-sink sink_name=VAC. This doesn't work with every application (they don't always detect monitor devices).
It can create a virtual audio connector using JACK as its backend.It allows you to save your patchbay and Studio session, which can save a lot of time. Especially if you need to launch additional shell commands.All you need to do is configure your microphone at Configure -> Driver -> Device.
Yes, I think exclusively. It is expensive though.
Actually, it is a bit over-kill for just a streaming interface, but I do use the extra capabilities to do post-processing with EQ and mild compression / auto-volume. You can add any Au or Vst plug-in into the chain.
Hi @DJKenJ, this is not officially supported, but using a virtual audio cable on the booth out automatically creates an aggregate audio device. You can open Audio MIDI setup, select that aggregate audio device and enable drift correction for the virtual audio cable. I hope that helps. Thanks!
The reason for this is that I want to use GNURadio to decode multiplechannels at the same time, and route the audio from the channelsdifferently. Specifically my goal is to usy my ICom 7300 in IF mode(which gives me 12kHz of audio bandwidth) tuned to both the FT8 andJS8 HF frequencies, and then let wsjtx listen on a virtual sound cardcarrying FT8, and JS8Call listen to a virtual sound card carrying JS8.
In the last post I said that PipeWire (like PulseAudio) builds on topof ALSA. This is only partly true. As I said in the end of that postALSA can also create virtual sinks and sources on top of the devices.
I have Virtual Audio Cable successfully installed on my Windows Server 2008 R2 SP1 x64 virtual machine. It seem like driver works (new audio device in Device Manager group and VAC control panel works perfectly), but unfortunately if you go to Control Panel -> Hardware -> Sound there is no audio devices (neither playback or recording). And so my software doesn't see any audio devices.
Audio is special in a lot of ways, and audio drivers run in the context of a "session" in Windows, so each remote desktop user gets their own audio. Even on a physical machine, when you connect via remote desktop, you see different audio devices in device manager from the ones you see sitting a local keyboard.
The short answer to your question is that a VMware virtual audio device will only be visible in the "console" session, not in secondary remote desktop sessions. You can remote audio through your remote desktop, with our without a VMware virtual audio device.
Virtual Audio Cable works fine with 2008 R2 , but it needs to be installed on a session basis, it will not replicate over RDP, you need to connect with Team Viewer or something similar to access the audio streams.
Virtual Audio Cable is a software product based on WDM multimedia driver that allows a user to transfer audio streams from one application to another. Any application is able to send an audio stream to the input side of a "virtual cable" while a corresponding application can receive this stream from the output side. Since all transfers are made digitally, there is no loss in sound quality. VAC is the audio equivalent of a MIDI loopback device such as MultiMid or Hubi, and can be used instead of "Stereo Mix" or "What U Hear" features of audio adapters.[1][2]
If more than one application is sending audio through an output virtual cable, VAC is able to mix all of the streams together or create separate corresponding virtual input cables. Similarly, more than one application is able to receive audio from an input cable, whether it's sharing the same audio data with another target or receiving its own personal audio stream.[3] VAC is useful for recording an application's audio output in almost real time or transferring a sound stream to another application so it may process it. A person could use two or more software audio generators, synthesizers or sequencers to produce audio streams and send them to a VAC output cable and record the mixed stream from the VAC input cable using any type of recording software.