Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Audio and virtual machines (Read 7810 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Audio and virtual machines

Hello,

I have posted this message on VMware's forum, but since I got no answers, I'm posting here too. These questions are for those who have some experience with VMs and audio, especially VMware Player. That's why some questions are specific to VMware Player. Sorry if you feel uncomfortable with them if you are not a VMware user. Anyway, all the answers will be greatly appreciated.

The message:

I plan on using a VM to work exclusively with audio: playing music, editing/converting some audio files, etc.
So I have some basic questions:

1. How does the audio work in a VM? Audio is sent to host before played or is it played directly from VM?

2. I'm really worried about sound quality. Considering the way things work, is there any loss in sound quality?

3. What about softwares that require direct access to audio hardware (sound card, CD/DVD drive, etc.)? Will they work in a VM?

4. What about hardware acceleration?

5. What about EAC/Lame running on a VM?

6. What about audio players (Foobar2000, etc.) running on a VM?

7. Some softwares act like an audio driver (for example FXsound's DFX) concentrating all of the OS's audio. Should they be installed on VM, only on host, or both?

8. VMware specific: In "Edit virtual machine settings > Sound Card" what's the difference between "Use default host sound card" and "Specify host sound card"?

9. VMware specific: What it is and when to use "Echo cancellation"?

Please, feel free to add more information and hints about this issue.
Your answers are very important to me. It will decide if I should use a VM for audio or not.

Thank you very much.

 

Re: Audio and virtual machines

Reply #1
I've played a bit with VMs, but only to get some old software to work, to be able to fetch the data. VMs aren't directly talking to sound cards, they create virtual cards, so they add additional layer in communication between software and hardware. ASIO is no-go in VMs, so is audio HW acceleration.
Why use VM for all that in the first place, what do you think it will accomplish?
Error 404; signature server not available.

Re: Audio and virtual machines

Reply #2
I haven't used VMware recently (last 10 years maybe), but virtualbox is quite similar in this regard.

There are two types of virtual machines, those that act at the hardware level ( usually called hypervisors ), and those that sort of emulate a computer.  The former are used to leverage a specific hardware and have multiple virtual machines that share the hardware resources.  The latter is what we are more used to, which is an "application" that runs on top of an operating system.

During the last 10 years, hardware has evolved in a way that several hardware elements can be shared at the hardware level, so the virtualization gets a speed boost. This is the case for example of the the VPro line of intel processors.

But when we talk specifically about audio, everything is still emulated:

1) Software on the Virtual machine sees a generic soundcard (with no ASIO support. Maybe installing ASIO4All would work, but I haven't tried it), talks with this virtual soundcard, then the virtual machine talks to the API of the physical soundcard and sound finally reaches the soundcard. So yes, it is the virtual machine the one that talks to the physical soundcard, not the virtualized software.

2) There can be audio issues depending on how complete the emulated audio driver is, and the API used to talk with the real soundcard. Issues include having only 16bits output, supporting a limited set of sampling rates, or even supporting just stereo. Internally it should not be too complicate to pass the audio from the virtualized soundcard to the API, but considering the target usage of audio on virtualized machines, it might be "just good enough".

3) As said before, you don't have direct hardware access from the virtual machine, except if the virtual machine is able to share the physical USB ports, and the OS on the physical side is not interacting with it. This way, the virtualized OS might be able to talk with the hardware. For the rest, the hardware is usually emulated, even if just with a thin layer that transmits the commands from the virtualized side to the physical side.

4) As said, there are some things that can be hardware accelerated, like the case i mentioned about processors, some graphics, if using specific APIs might get accelerated (or at least rendered by the physical graphics card instead of the emulated one), and you might have direct access to some other hardware via USB, but usually, you don' get hardware acceleration.

5) There's nothing special about LAME. About EAC, it will work if the virtualized CD has the API implemented. In that case, it will act as a layer that communicates with the physical hardware, as if the virtual machine was "EAC".

6) There is nothing special about audio players. Audio players talk to APIs of the Operating system, which in turn talks with the hardware, either emulated or physical. Just remember that they will only see what the virtual OS has, not what the physical OS.


7) That depends on the intended usage. The virtualized software will only see the hardware that the virtual operating system has. It does not know about the physical OS. So you probably want to install that in the virtualized OS.

8 ) Since it is the virtual machine the one that talks with the soundcard, and the virtualized software only sees a virtualized soundcard, it lets you select which soundcard is it going to use.

9) I'm not sure what is the intended usage scenario, but echo cancelation is used for microphone recording, where it tries to reduce/erase its own output.  (I.e. in a webcam-like scenario, echo cancellation prevents you from hearing yourself on the other side's audio).


Re: Audio and virtual machines

Reply #3
If you want to do recording or anything like that I think the only way to do this is to use something like VirtualBox's (haven't use VMWare for quite some time) guest extensions with USB controller support and then pass your USB audio interface through to the guest.

Otherwise it's probably gonna be like some extra layer above the host DirectSound.
"I hear it when I see it."

Re: Audio and virtual machines

Reply #4
I've played a bit with VMs, but only to get some old software to work, to be able to fetch the data. VMs aren't directly talking to sound cards, they create virtual cards, so they add additional layer in communication between software and hardware. ASIO is no-go in VMs, so is audio HW acceleration.
Why use VM for all that in the first place, what do you think it will accomplish?
Thank you for your answer.
Usually I create a VM for some specific tasks. This way I keep my host OS as clean as possible and also can use the VM in another computer.

Re: Audio and virtual machines

Reply #5
If you want to do recording or anything like that I think the only way to do this is to use something like VirtualBox's (haven't use VMWare for quite some time) guest extensions with USB controller support and then pass your USB audio interface through to the guest.

Otherwise it's probably gonna be like some extra layer above the host DirectSound.
Thank you for your answer.

Re: Audio and virtual machines

Reply #6
First, thank you for your great answer. It helped me so much.
Some doubts:

2. I'm really worried about sound quality. Considering the way things work, is there any loss in sound quality?
2) There can be audio issues depending on how complete the emulated audio driver is, and the API used to talk with the real soundcard. Issues include having only 16bits output, supporting a limited set of sampling rates, or even supporting just stereo. Internally it should not be too complicate to pass the audio from the virtualized soundcard to the API, but considering the target usage of audio on virtualized machines, it might be "just good enough".
I'm using Win10 x64 and Creative Sound Blaster X-Fi Titanium HD PCI soundcard in my host computer.
VM's OS is also Win10 x64 and I can see in its "Device Manager > Audio Controllers" there is a "High Definition Audio Device" installed.
It seems a "generic" device. Its advanced properties shows many sampling rate options: 16bits/44100Hz to 24bits/192000Hz.
Can I expect some sound quality?

7. Some softwares act like an audio driver (for example FXsound's DFX) concentrating all of the OS's audio. Should they be installed on VM, only on host, or both?
7) That depends on the intended usage. The virtualized software will only see the hardware that the virtual operating system has. It does not know about the physical OS. So you probably want to install that in the virtualized OS.
In fact, FXsound's DFX appears in "Device Manager > Audio Controllers" of host OS and it's the default "soundcard".
It provides an enhanced audio quality. All of the audio goes through it when it's enabled. Maybe installing on both host and VM OS could create a kind of distortioin. What do you think?

Thanks again.

Re: Audio and virtual machines

Reply #7
I'm using Win10 x64 and Creative Sound Blaster X-Fi Titanium HD PCI soundcard in my host computer.
VM's OS is also Win10 x64 and I can see in its "Device Manager > Audio Controllers" there is a "High Definition Audio Device" installed.
It seems a "generic" device. Its advanced properties shows many sampling rate options: 16bits/44100Hz to 24bits/192000Hz.
Can I expect some sound quality?

Correct, that's a generic driver. In the case you describe, it supports high bitrate and sampling rates so there might not be sound quality issues on the virtualized side. On the host side, it probably interacts with directsound.
Sometimes, the virtual machines offer some specific drivers to improve compatibility (in case of virtualbox, it's called virtualbox additions and emulates a driver CD so that you can install them. In this case, it helps on folder sharing and UI responsiveness/mouse integration).

What you might need to do is to configure the different soundcards (physical, "FX", and virtualized) to use the same sampling rate in order to avoid resampling)

In fact, FXsound's DFX appears in "Device Manager > Audio Controllers" of host OS and it's the default "soundcard".
It provides an enhanced audio quality. All of the audio goes through it when it's enabled. Maybe installing on both host and VM OS could create a kind of distortioin. What do you think?

Oh, then I didn't understand what that software was for. I thought it was more like a virtual soundcard to interconnect software, but as you describe it, you use it just as an FX processor before the final output. Then, it doesn't need to be on the virtualized OS, and you would configure the virtual machine to output to this "soundcard" (which you're saying it is the default already).

Re: Audio and virtual machines

Reply #8
Disclaimer -  I don't know much about virtual machines....

Quote
2. I'm really worried about sound quality. Considering the way things work, is there any loss in sound quality?
At the software/digital level it's "just numbers" and there's no reason for the audio to be damaged.

Even if  it  gets resampled somewhere along the way, resampling is normally transparent (as long as it stays at "CD resolution" or better.

Of course, you could run into a situation where the drivers aren't supported and in that case you wouldn't get any sound at all, or you may not get all of the features of your soundcard/interface, but "sound quality" shouldn't be affected.

If the audio stream does get damaged, it's going to be timing related glitches.    Obviously, the audio stream has to flow-in (if recording) and flow-out at a smooth-constant rate and most digital audio related problems are  related to buffer underflow/overflow.    Usually this type of glitching is usually obvious and annoying (it doesn't require careful listening or  "golden ears" to hear it).

I'd guess that real-time monitoring/processing would be a problem...    You'd probably get latency (delay) issues.    Latency is often an issue with a native operating system and more layers of processing is likely to make it worse.