Quality audio from within Virtual Machines?

I'm planning to move my music-playing system from a failing laptop to a virtual machine instead. The exact configuration is yet to be decided, but the host system will be Linux running either QEMU/KVM or VirtualBox. The guest OS would 'preferably' be also Linux.. there are a few excellent windows applications that continually tempt me, so that might still be an option, but just personally I'm not keen on where windows is headed so am trying to get up to speed on Linux instead.

The output will be to a DAC or high-quality external sound-card (there is the option of an internal card but I've had bad experiences of noise when the analogue section is within a full-blown PC). It will probably be multi-channel, even though I only play stereo, in order to allow digital-software crossovers.

Anyway, I've not tried to run serious quality audio from within a virtual machine before, so am quite naive about it. It might be a complete non-issue, or conversely there could be all sorts of pitfalls that I'm not aware of - as the audio is sent from within to without. So please forgive my ignorance and if anyone has experience of this I'd appreciate any thoughts on what problems might be encountered or what measures might need to be taken (if any) etc.

Many Thanks,
Kev
 
Unless it's got to share a laptop/pc with other software and is a custom distribution I'm not sure I understand the 'why' of using a VM unless it is to continue to use older and end-of-life software??? In any shared environment there's going to be contention for resources and a VM won't save you from the problems that can present. Generally though on any modern well specced PC it's not likely to be a problem unless you're doing something else CPU/memory/I-O intensive.

There are a lot of very good streaming/playback options with custom Linux distributions to run on the RasPi, you can add DAC hats or whatever you want. The hardware is relatively cheap, the results are excellent. Moode, Volumio.
 
Thanks both. It is (of course) easy to produce sound from a virtual machine, I was more worried about potential degradation in quality. So looking at jiiteepee's link has helped me to visualise things a little more clearly, thank you. Hopefully if one selects the host OS's driver then virtualbox might simply just pass it through without doing anything to the audio.

Yes I've been down the route of separate machines, including the Raspberry Pi and fanless laptops; it was quite a lot of fun and did work well. However some recent hardware failures have offered the opportunity to reconsider. Life has changed: I have 'much' less time these days and always listen in the same room now, so a simple setup with everything on the main/existing PC there would suit me better - essentially I've no longer any reason to use additional computer hardware just for playing audio.

Though 'if' there are no serious sound quality issues, I would prefer to run it from within a VM; as a hobby, I'll want to tinker with things and run software and network protocols etc that aren't entirely ideal for a machine also used for work, so some separation would be helpful. It has a current generation i7 CPU, 64Gb of ram and I'm currently making it fanless, so it should be suitable. I think that modern PCs are reaching the point where the overhead of VMs is not really a problem for modest applications such as this. If it goes well my days of buying and maintaining separate (computer) hardware for various purposes might possibly be over (except for special cases such as built-in receivers or crossovers). I hope that reasoning makes sense, anyway.

Thanks again,
Kev
 
One aspect of VMs (specifically VirtualBox) is it has only supported a single thread for USB. This means a USB audio device such as a USB stream to a DAC has to compete with any USB connected devices for processing power. I'm not sure if that has changed since I last looked.

USB isn't a guaranteed bandwidth and latency bus anyway so streaming USB is not guaranteed to be brilliant without some device FIFO buffering.
 
Your reasons make sense and it will make it easy to transport the system to other platforms and to have a safe fall back when you tinker. I'd considered doing something similar but had a few RasPi 3's around the house from other projects so they were cheap to set up. Duplicating SD cards may be slower than copying VMs but you get the same overall effect. I've had no reliability or performance issues and Moode is very actively developed and support forums are responsive.

64gb? Envy!!!!

Can't think you'd see any degradation in quality except, perhaps, from jitter. But it can be reclocked. But that's an area that as clear as mud to me and there are others here who're much better able to advise on this. But I'm not sure that being in a VM is going to make any difference to the degree to which there's jitter.

Please post back with your experiences, I'd be interested to know how you get on...
 
Thanks again for the thoughts, that is helpful. Yes I will report back on how it goes, certainly on a practical level - the quality thing might be more subjective since I don't have any means (or any great inclination) to try measuring jitter and so on. I guess that if I'm happy with what I hear and there are no audible (to me) artifacts introduced then I shall be satisfied.


One aspect of VMs (specifically VirtualBox) is it has only supported a single thread for USB. This means a USB audio device such as a USB stream to a DAC has to compete with any USB connected devices for processing power. I'm not sure if that has changed since I last looked.

USB isn't a guaranteed bandwidth and latency bus anyway so streaming USB is not guaranteed to be brilliant without some device FIFO buffering.
Ah, thank you; that might be something to consider if it is still so. I shall have to see if I understand the implications of that; maybe if VirtualBox passed the audio to an intermediary such as pulseaudio then it may not need to get involved with USB (only the host OS would) - or is that incorrect reasoning?

Then too there would be alternatives such as qemu or a PCIe sound card. A purely digital output card would overcome concern of PC noise on an analogue stage, so isn't out of the question.

Thanks,
Kev
 
USB isn't a guaranteed bandwidth and latency bus anyway so streaming USB is not guaranteed to be brilliant without some device FIFO buffering.
You're at the mercy of the firmware. I have a Dell XPS 13 (a 2016 model) that I was using to make recordings. Using an ADC-->USB-->laptop using VinylStudio and found there were regular (every 15 minutes to the millisecond) ~100 mill sec gaps in the recordings where the signal was paused then resumed. Tried Audacity and got the same. Tried different PCs and had no problems with those. If I deleted the gaps the waveforms lined up, so it was a pause, not a cut.

I didn't even know where to start with trying to get Dell to look at it 🙁

USB can be mysterious and you're at the mercy of the firmware implementation. I believe on some smaller systems USB shares networking and other hardware resources. From Kev's description his PC is going to be well specified so probably safe...
 
I use a Mac mini with 32GB and Virtualbox for linux (ubuntu mainly) for various reasons. One includes a software AWG generator that connects to the SDS1104X-E scope to provide my bode plots. The sound is limited to 20KHz due to the brick wall filter in the mini's headphone jack however it works enough to get an idea.

I am interested in building an FFT plugin for a TI instruments 32bit 1MSPS ADC board which would plug in via USB. The low noise level would out class most sound cards and the oscilloscope's FFT function. So far I've done quite a bit of design theorising.
 
Thanks again for the thoughts, that is helpful. Yes I will report back on how it goes, certainly on a practical level - the quality thing might be more subjective since I don't have any means (or any great inclination) to try measuring jitter and so on. I guess that if I'm happy with what I hear and there are no audible (to me) artifacts introduced then I shall be satisfied.



Ah, thank you; that might be something to consider if it is still so. I shall have to see if I understand the implications of that; maybe if VirtualBox passed the audio to an intermediary such as pulseaudio then it may not need to get involved with USB (only the host OS would) - or is that incorrect reasoning?

Then too there would be alternatives such as qemu or a PCIe sound card. A purely digital output card would overcome concern of PC noise on an analogue stage, so isn't out of the question.

Thanks,
Kev

Virtual box is a hypervisor - it connects in at a hardware level. Therefore the USB is switched between the host OS and the VM OS. Either OS would have constraints and couldn't guarantee latency both due to the non-realtime OS and due to the USB bus protocol. Ethernet/WiFi is also not guaranteed.
You're right in that it's feasible that you'd get a quality you'd be able to use and on the odd occasion that would then cause some breakup etc however that's very dependant on the specific machines involved, the patch/releases of the OSes and software, the environment and the rate of streaming data transfer.

Output via optical SPDIF from a PCI card would help bypass USB and interact on the main bus. Although every bus has conflict but this is faster thus less impact unless you're really hammering the machine at which point the USB stream would have given up way earlier.

Then you're into the realm of digital streaming jitter etc and down the rabbit hole the conversation goes 😀 For most easy access listening it's likely to be good enough.
 
Great stuff, thank you for all that info, I think I understand things better as a result. It seems reasonably promising, also with some alternatives if required, so I shall try it then and see how things go with the particular hardware.

This system won't be used for things like recording, so isn't critical in that sense. It will be for fairly serious listening, but I don't have unusually high-end audio equipment (or ears), and these days I refuse to obsess too much over things I can't actually hear in direct comparisons. So it seems there is a reasonable chance of being very suitable for my purposes, if all goes well.
 
This highlights one of the problems with much of modern software based technology; there's no-one who has a good grasp of the operation of all of the dependencies in any piece of software (except maybe Linus Torvalds). The dependency chains are long and with complex interactions from user level software, through the OS, device drivers and firmware.

It's not long before so-called problem solutions found online devolve into the equivalent of claiming that sacrificing a chicken fixes things.

It's an unholy mess where fault finding is painstaking and slow, particularly with multi-process/threaded systems where even reproducing a problem can be nightmarish. My biggest qualm about using VMs is that they introduce another set of complex dependencies into an already complex set and that they make diagnosing faults yet more complex, with more logs, more threads, processes and semaphores controlling time sensitive operations in an opaque fashion.

We worry about the impending singularity and the extermination of humans by their robot overlords, but I think it's far more likely we'll be driven insane by technology failing when it devolves into an unholy hybrid of Dark Star's talking bomb and H2G2's Lintilla clone factory.

Happy listening. It's all any of us really want.
 
Yes, if I can listen happily then all will be well.

There will be a small delay on the VM front because I've decided first to disassemble the PC and make some hardware alterations beforehand. The record hot spell we just had here leads me to think that a passively cooled PC probably can't have too many vents and heatsinks so the cooling and the case are getting reconfigured first.

Cheers,
Kev
 
Right now I have VMWare Player running Win10, hosted on ubuntu. VMWare Player instead of Virtualbox due to better support for 3D acceleration on my HW which I need in Win10.

IntelHDA emulation works fine, IMO bitperfect from alsa HW devices on the host, formats standard IntelHDA i.e. S16LE and S24LE/S32LE. USB passthrough to the guest is not 100% reliable, I sometimes notice dropped packets on the guest at bInterval 125us.
 
Hi,

If you decide to go with QEMU/KVM and your hardware supports IOMMU then you can directly expose your PCI devices (sound cards, GPUs, USB controllers) to the VM. It takes a bit of tinkering, but the benefit is that the devices run nearly at native speeds under VM.

Anyway, just a thought.

F
 
Thank you, both. As the thread progresses, it seems that my concerns of things not being quite seamless via a VM are not entirely without foundation then, but it is also heartening to hear that they can be made to work so well - likely more than adequately for me.

I have used QEMU/KVM for guests doing simple things, and in combo with virtual manager I have been quite impressed. But IOMMU is new to me so I need to do some research there - starting with whether my system would even support it.

I suppose if the VM did start getting too annoying, a dual setup could be created instead. With a trusted simple player running natively on the host for highest/easiest play-back quality, and a VM for all the less ideal network, software and tinkering type activities that I'd like to use - probably both sharing a 'music' partition for the content. Not free of compromise but a possible fall-back if things don't fully work out with a VM-only approach.
 
Work has intruded recently, so I've not got very far with this yet. However I have been researching + thinking a bit more and have decided that USB is going to be quite important to me.

Some of the DACs that I'm most interested in have USB input only - it seems to be perhaps the most popular interface for PC-oriented DACs. It will be the most flexible interface for moving between different machines if/as needed - including laptops, tablets SBCs etc. It also looks to have received a goodly amount of work in recent years into things like jitter reduction and higher data rates; most of the old/original concerns appear to be essentially obsolete on decent modern hardware - even low powered devices like the latest raspberry Pi now have few issues.

By default, USB doesn't offer the inherent ground-loop protection that optical methods do. However, there are ways of dealing with that, and apparently good modern DACs tend to do so fairly well; besides, it shouldn't be a great problem for my intended configuration anyway. They key thing (based on my past experiences) is that it remains a digital output from the electrically/electromagnetically noisy PC - the analogue stage is still situated somewhere quieter.

From what has been said above, probably such a USB configuration would be fine in virtualbox. But given the slight reservations mentioned, I've decided that I may as well go with KVM/QEMU instead for my first attempts; this is fairly native to Linux so appeals to me, and I can't find anything that says it restricts threads for USB. Though that may mean little because I can't find much on VirtualBox doing so either; unfortunately i'm not a highly technical PC user so am probably searching with the wrong terms. However I have used KVM/QEMU before with virtual manager (albeit in simple applications without any special IO requirements) and it was quite usable, so seems worth a go in the first instance.
 
I've not entirely forgotten about this, just been struggling for free time. However, I've prepared the PC for its new role by making it silent, re-shaping/reducing the case to make it fit on a hi-fi rack, and making it considerably more vented.

The micro-ATX motherboard in the ATX case just left room for the PSU and optical drive at what was the bottom of the case, rather than in front of the mobo. I've also got no intention of using big/long graphics cards. So the front-to-back depth of the case could then be almost halved. It was also turned on its side to make a desktop (rather than tower) configuration. And obviously all sides were cut open and replaced with stainless steel mesh. It is still somewhat bigger than a mini-ITX but now quite compact enough for my purposes.
Quiet-Vented-PC.jpg
The PC was already designed to be pretty quiet, so not a lot of changes were needed internally to make it fully so. The mobo (an MSI Mag B660M mortar) already has fairly decent heatsinks and temperature controls etc. The CPU is an i7-12700 that has (for an i7) a fairly low thermal design power, which allowed the use of a passive CPU cooler (noctua NH-P1) without much performance compromise, and also a modestly rated fanless PSU (seasonic PX-500). Since there is usually an assumption of some airflow inside a case, I added passive heatsinks for the SSDs and an additional one for the chipset. There are actually a couple of fans, but just as a contingency; they should not come on except in unusual circumstances (and I can't hear them from the listening position even then).

Next time I'd probably just buy a more suitable case, as the customisation took far longer than I'd anticipated. However it is done now, I've more or less got what i wanted, and can soon move on to the more interesting part of testing the virtual machines and getting all the audio-playing stuff running.
 
Well some very early tests with QEMU/KVM have found a few useful things.
  • The sound from a guest VM to the PC's inbuilt audio card works by default. Though there are some quality issues and also latency ones (e.g. sound can lag video). This may be easily solvable, but I haven't tried as I'm not actually intending to use the PC's sound card; for me, it just confirms that things can be less than normal from within a VM.
  • I then tried passing through the USB DAC (that I intend to use) to a VM, and got horribly distorted sound. Reading around, passing through individual DAC/USB devices seems a bit hit-and-miss; it is often advised to instead pass-through the whole USB controller.
  • Passing through the whole PCI USB controller did indeed work much better. Though my testing was quite limited because I only have the one USB controller, and so lost the use of other things like keyboards etc. by passing it through.
So.. the next step could be to get a second USB controller, to dedicate to the VM. It needn't be expensive and would seem to be the neatest answer.

Otherwise I could side-step the complication by just using the host for playing (and maybe ripping) - and still do general tinkering, tagging, downloading, media-serving etc. in a VM. But it would be much more convenient to have all music-related stuff in one hobby-oriented VM. Especially when it comes to things like live music streaming from the net to the DAC (which I'd prefer not to involve the host work-oriented machine in directly).