VOGONS


Reply 20 of 51, by darry

User metadata
Rank l33t++
Rank
l33t++

I just tested one of the ADS Tech Instant Music devices in Loopback with a U2 (both through Pipewire and JACK/Zita). I also did a recording test of an RMAA generated test file . The results are virtually identical to those with a CM6206 in all cases, which is not unexpected .

On another note, having given some more thought to the latency aspect, it struck me that the U2 (based on the XMOS XU208) is a UAC2 class USB audio device which runs in USB high speed mode (UAC2 allows the use of high speed mode but does not make it mandatory, so being UAC2 compliant does not guarantee use of high speed mode, AFAICT). This probably helps explain why I can set a period size as low as 32, or even 8 on the U2, but am limited to 45 (for 44.1KHz) or 48 (for 48KHz) for all UAC1 class 1 devices that I have tried setting low period sizes on (SPS-25, CM106, InstantMusic, UCA202). Additionally, UAC2 exposes information about device clock domains to the host, which may alleviate the need for resampling due to different clocks, at least in a scenario where there is only one source and one sink, if my understanding of http://visa.lab.asu.edu/gitlab/fstrace/androi … b1456a3cef310f0 is correct .

All this brings up the interesting questions

a) Would using UAC2/high-speed captures devices yield lower latency while also avoiding all my previously worked-around USB 1.1 issues ?
b) Would doing a) change my results in Pipewire ?
c) Are there any UAC2/high-speed captures devices with S/PDIF input available and, hopefully, affordable ?

I am willing to test a) and b) for myself, if I can answer c) . The ONLY possible answer to c) that I have found, so far, is https://www.minidsp.com/products/usb-audio-in … ace/usbstreamer . At 95 $US a pop, this is not eye-wateringly expensive (and certainly very reasonable for a niche product), but with duties, taxes and shipping, I would be looking at adding over half a grand $US to the BOM for 4 units . Obviously, I could just get one to test first, but if it works well, the temptation to get a few more would be hard to resist . Anyway, I will keep searching for cheaper alternatives .

EDIT : I installed and updated the latest Raspbian/Raspberry Pi OS 64-bit beta release and managed to compile a modern RT patched kernel for it (5.10.27) . I gave up on trying to run with Ubuntu Budgie's 5.11.0 kernel source (couldn't get it to patch successfully, maybe I was doing something wrong).

Anyway, public service announcement for anyone interested in compiling a Real-Time ( Fully Preemptible) patched kernel for an ARM64 platform:

Since somewhere around the 5.9 kernel version, to choose a Real-Time kernel preemption model, one must

a) Make sure to first complete the step that involves running "make bcm2711_defconfig" BEFORE running b) and c) or your changes will be overridden (you will end up with a non RT kernel)
b) Run make menuconfig and Disable Virtualization
c) while still running make menuconfig , make sure Configure standard kernel features (expert users) is enabled and exit/save settings

After that, following http://robskelly.com/2020/10/14/raspberry-pi- … and-preempt_rt/ and https://www.raspberrypi.org/documentation/lin … nel/building.md works fine as long as you are cross-compiling . If you are compiling locally on a Pi , the instructions in the second link will need to be modified as they are specific to building a 32-bit kernel (basically replacing zImage with Image and KERNEL=kernel7l with KERNEL=kernel8 )

It took me a while to find information pointing to points b) and c) .

EDIT2: Everything seems to work on newest Raspbian 64-bit beta with the RT patched 5.10.27 kernel . My search concentrates now on finding inexpensive UAC2 capable S/PDIF input devices that run in high-speed mode . If I manage to find some that are affordable, it could, as alluded to before, potentially simplify and cost reduce the setup by allowing use of a standard low cost PSU and a single low-cost USB 2.0 or 3.0 hub rather than having to resort to a USB PD capable hub and and a multi-TT hub, both of which are relatively expensive and and the second of which is additionally getting harder to find .

That all being said, if 12 milliseconds worth of latency and cheap shoddily built CM6206 (but sill functional) USB interfaces (or more expensive, harder to find, better built InstantMusic ones) are acceptable in someone's use case scenario (they are in mine), this solution is perfectly usable as is .

EDIT3: I have managed to find what I believe is a candidate for USB 2.0 highspeed UAC2 capture device with S/PDIF input at reasonable-ish price . It is based on the BRAVO/Savitech SA9226 https://datasheetspdf.com/pdf-file/1306864/SAVITECH/SA9226/1 , which I cannot even find on https://www.savitech.co/usb-products , which suggests that it might be discontinued (not an issue for me if availability is good). Anyway, I will test for suitability when I receive the unit that I have ordered .

Reply 21 of 51, by darry

User metadata
Rank l33t++
Rank
l33t++

I decided to go deeper down the rabbit hole.
I ordered :

- a Pi 4 compute module
- a CMIO4 breakout board which has a PCI Express slot
- a PCI Express bridge board with 4 PCI Express slots
- 4 Creative SB1040 sound cards (based on the CA0110 chip). EDIT : Spec sheet for CA0110 : https://web.archive.org/web/20100215044637/ht … hips/CA0110.pdf

It is easy to imagine where this is going...

Reply 22 of 51, by darry

User metadata
Rank l33t++
Rank
l33t++

Long story short : everything works, including the PCI Express bridge, EXCEPT for the sound cards.
Typically, kernel module loads (or can be loaded manually using modprobe), but no ALSA devices are available (nothing in /proc/asound/card* for the device). Using the aforementioned bridge (ASM1184E) and also a Startech PCI Express to PCI one , I tried :

SB1040 PCI Express (also tried this one directly in the PCI Express slot without using a bridge and got the same results)
SB0410 PCI
SB0610PCI
generic CM8738 based PCI card

Am I missing something really obvious ?

P.S. For the SB1040/CA0110 , I also tried compiling as kernel driver rather than a module and got the same results .

EDIT : I got the SB1040 to work, but only when connected directly to the PI's PCI Express slot . It does not work through my ASM1184E based bridge/switch . See https://www.raspberrypi.org/forums/viewtopic. … 306055#p1854874 for more details .

Reply 23 of 51, by darry

User metadata
Rank l33t++
Rank
l33t++

I finally did get the 4 SB1040 cards working off of the ASM1184E PCI Express switch, but not on a Pi 4 . I did get everything to work on an x86-64 machine (HP Compaq 6200 Pro SFF) under Ubuntu 21.04. Along the way I found out that, at least on this x86-64 setup, the SB1040 cards would not work through the ASM1184E if using an RT patched (Fully preemptible) kernel. Using a low latency (Preemptible) kernel did allow the SB1040 cards to work through the ASM1184E on the x86-64 setup . On the Pi 4, I never got the cards to work through the ASM1184E, no matter the kernel type . I am still using the USB Douk U2 for output . P.S. I had some issues with SB1040 cards in the beginning, but adding this to alsa-base.conf fixed them : options snd-hda-intel index=1,2,3,4 enable_msi=1 bdl_pos_adj=2,2

Effective latency through the mixer on the x84-64 setup with the SB1040 cards and the U2 is about 9.7 milliseconds .

I also tried Pipewire on this x86-64 setup, but got the same intermodulation distortion issues as on the Pi 4 .

Oh, and as an added benefit of SB1040 cards, 24-bit input now works (Zita resampling of the synthetic test samples used, I theorize, seems to be causing noise levels to go impossibly low, which is probably a measuring/calculation artifact of some kind) :

24bit.png
Filename
24bit.png
File size
40.42 KiB
Views
2114 views
File license
Public domain

At this point, for my needs, it looks as though I am going to settle on running this on the x86-64 machine, at least for the time being . I will do more testing on the Pi 4 when I receive some of the Pericom based PCI Express switches that I have on order .

The good news, for someone wanting to do this, is that using a cheap and quiet SFF PC that is likely easy to find can be a decent alternative to a Pi 4 based setup (albeit bigger and more power hungry), especially if lower latency and/or 24-bit support is desired .

EDIT: Total power draw when running my x86-64 setup is 51 watts at AC wall socket (not including monitor/screen)

Reply 24 of 51, by darry

User metadata
Rank l33t++
Rank
l33t++

I decided to run some comparison tests between resampling done by Zita-a2j in the DIY mixer setup versus the internal hardware resampling done by an SB Live! CT4830 .

In one case, the signal went through one of the 4 SB1040 cards in the input bank, was resampled in software (Zita) and was output through a Douk U2 .
In the other case, the signal went into an SB Live! , was resampled in hardware and was output by the same SB Live!

In both cases, 44.1KHz was input digitally (S/PDIF), converted to 48KHz, was received digitally (S/PDIF) and was analyzed by RMAA .

comparison.png
Filename
comparison.png
File size
40.02 KiB
Views
2076 views
File license
Public domain

Detailed RMAA comparison tests :

Filename
tests_rmaa.zip
File size
176.34 KiB
Downloads
58 downloads
File license
Public domain

Reply 25 of 51, by darry

User metadata
Rank l33t++
Rank
l33t++

Another potential inexpensive, small footprint and low consumption hardware option is to repurpose an old laptop or EOL Chromebook device ( will require being able to convert it to running Linux). This would also require that

a) the device in question be equipped with a Mini PCI Express slot that does not have a device whitelist
b) something like this https://www.newegg.ca/p/1W7-00J9-000K6?Item=9SIAKCSCTN8266 be used to break out the MiniPCI Express slot to an x1 PCI Express slot into which a PCI Express switch can be connected .

I thought of this when I realized that I should probably check the Auto Update Expiration (AUE) date for my wife's Lenovo N22 Chromebook (it has about 11 months to go). When my wife stops using it, I will probably give https://www.schroer.ca/2017/01/31/chromebook-linux/ a shot .

Reply 26 of 51, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie
darry wrote on 2021-07-07, 02:38:
Another potential inexpensive, small footprint and low consumption hardware option is to repurpose an old laptop or EOL Chromebo […]
Show full quote

Another potential inexpensive, small footprint and low consumption hardware option is to repurpose an old laptop or EOL Chromebook device ( will require being able to convert it to running Linux). This would also require that

a) the device in question be equipped with a Mini PCI Express slot that does not have a device whitelist
b) something like this https://www.newegg.ca/p/1W7-00J9-000K6?Item=9SIAKCSCTN8266 be used to break out the MiniPCI Express slot to an x1 PCI Express slot into which a PCI Express switch can be connected .

I thought of this when I realized that I should probably check the Auto Update Expiration (AUE) date for my wife's Lenovo N22 Chromebook (it has about 11 months to go). When my wife stops using it, I will probably give https://www.schroer.ca/2017/01/31/chromebook-linux/ a shot .

I would be really interested in using one of my existing windows machine as a sort of audio server. Very cool! Less than 10ms of audio lag is negligible and the hit to quality is basically unmeasurable. I would need a for dummies guide though. I have been following this thread but it is way over my head 🤣. Also, any chance it w0uld work with the digital out header on an optical drive? The dream I think is to mix my DOS cards opl3 output with CD audio and midi.

Reply 27 of 51, by darry

User metadata
Rank l33t++
Rank
l33t++
mothergoose729 wrote on 2021-07-07, 02:58:
darry wrote on 2021-07-07, 02:38:
Another potential inexpensive, small footprint and low consumption hardware option is to repurpose an old laptop or EOL Chromebo […]
Show full quote

Another potential inexpensive, small footprint and low consumption hardware option is to repurpose an old laptop or EOL Chromebook device ( will require being able to convert it to running Linux). This would also require that

a) the device in question be equipped with a Mini PCI Express slot that does not have a device whitelist
b) something like this https://www.newegg.ca/p/1W7-00J9-000K6?Item=9SIAKCSCTN8266 be used to break out the MiniPCI Express slot to an x1 PCI Express slot into which a PCI Express switch can be connected .

I thought of this when I realized that I should probably check the Auto Update Expiration (AUE) date for my wife's Lenovo N22 Chromebook (it has about 11 months to go). When my wife stops using it, I will probably give https://www.schroer.ca/2017/01/31/chromebook-linux/ a shot .

I would be really interested in using one of my existing windows machine as a sort of audio server. Very cool! Less than 10ms of audio lag is negligible and the hit to quality is basically unmeasurable. I would need a for dummies guide though. I have been following this thread but it is way over my head 🤣. Also, any chance it w0uld work with the digital out header on an optical drive? The dream I think is to mix my DOS cards opl3 output with CD audio and midi.

I had never really considered doing this under Windows . I have no doubt it's possible, but I suspect commercial ($) software might be necessary. Also, TBH, I do not know where I would to start under Windows to try and do this, but I can certainly do a bit of research .

However, I'd be happy to assist in getting a Linux setup working on your end (if you have a spare PC), including, but not limited to, adapting the main script, udev script and any other config files to your particular config . The way I see it, this would allow me to interactively write and test a detailed how-to procedure (i.e. dummy guide) to also help the potentially 2 or maybe even 3 or so other people on the planet who may have an interest in this in the future 😉 Seriously there are probably (hopefully) more people interested, but lack of a detailed how-to probably discourages most of them from the get go.

IMHO, it is probably simpler to set up than it currently looks to you due to the many tangents and left turns I have taken along the way. Also, unless you absolutely can't live without 24-bit input (instead of 16-bit) and/or 10 milliseconds of latency (instead of 12 milliseconds), I would suggest you try, at least at first, with cheap USB CM6202/CM106 cards for input . For output, the USB Douk U2 is a good choice, IMHO .

Digital out from an optical drive is definitely doable. Obviously, the signal would need to be routed externally from the retro PC and converted to proper coaxial S/PDIF level or to optical S/PDIF (see below) .

WARNING : What I wrote below regarding levels may not be 100% accurate and is based on what I have read and tested as working. I have made any actual measurements . I have no idea how likely risk of damage is if connection without level conversion is done .

However, since the digital out from a CD-ROM is, AFAIK, is S/PDIF and usually (always?) 5V, instead of 0.5V or so (normal coaxial S/PDIF level), peak to peak (in either case), level conversion either with a DIY adapter like one of these https://www.epanorama.net/documents/audio/spdif.html or, more simply, with a ready-made bracket like one of these https://www.amazon.ca/gp/product/B07FJMD7BF/ which, if I am not mistaken, are designed to be connected to the 3.3 or 5V level (TTL) S/PDIF output on motherboards will be necessary. See also Re: Pure DOS gaming system with 100% digital audio output and Re: Multichannel analog+digital DOS mixer for multi format DOS sound builds, COMING SOON! Also, some coaxial S/PDIF inputs accept either normal or TTL levels (this is not always advertised/specced).

Reply 28 of 51, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie

Thank you Darry! You're awesome, you don't know how much time and money I have sunk into trying to do this from the analog side.

I have tried really hard to get an analog mixer setup working and it is way too difficult. The world of amps, and preamps, and line ready condition blah blah is all black magic, and I think there probably isn't a way to do it without hurting audio quality at least a little bit. An all digital mixer would be so much easier and better.

I have a PC in mind for this project, but it is already doing double duty as a midi emulator. I'll see if I can replicate my setup first in linux and test my stuff before I bother you with too many questions.

Reply 29 of 51, by darry

User metadata
Rank l33t++
Rank
l33t++
mothergoose729 wrote on 2021-07-08, 05:38:

Thank you Darry! You're awesome, you don't know how much time and money I have sunk into trying to do this from the analog side.

I have tried really hard to get an analog mixer setup working and it is way too difficult. The world of amps, and preamps, and line ready condition blah blah is all black magic, and I think there probably isn't a way to do it without hurting audio quality at least a little bit. An all digital mixer would be so much easier and better.

I have a PC in mind for this project, but it is already doing double duty as a midi emulator. I'll see if I can replicate my setup first in linux and test my stuff before I bother you with too many questions.

I have sunken a fair amount of money too doing trial and error for this project (and PC audio in general), so I think understand where you are at on that point .

Disclaimer/full disclosure : I am not an expert at either digital audio or analogue audio nor do I likely have anything close to a complete grasp on audio mixing best practices in either the digital or analogue domains . I am just experimenting/learning as I go along . Also, in both analogue and digital domains, keeping levels in check is important to maximize dynamic range. keep noise levels (digital and analogue) as low as possible/practical and avoid clipping distortion . Once things are configured, things should be quite simple and straightforward to operate .

When you have some time, feel free to PM me and we could set up a voice call to discuss things further .

Reply 30 of 51, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie

After doing some research I have some ideas. Let me know if you think this will work...

I found these USB devices that are a little cheaper then the one you use and apparently that work in linux. It apparently uses the C-Media CM6206-LX chip... whatever that means.

https://www.amazon.com/Channel-External-Surro … 25808666&sr=8-7

A comment claims heaps of input lag but that is is in windows, I bet that has more to do with the drivers and software than the hardware. What do you think?

This is the one you linked earlier, I think.

https://www.amazon.com/Optimal-Shop-External- … 25809093&sr=8-8

I don't think I can replicated my midi setup in linux, at least not easily. Falcosoft midi player is windows only, I am relying on some plugins from roland I don't want to fuss with, and the Roland USB midi interface could probably be made to work in linux or a similar USB adapter could work but I don't' want to do that if I can avoid it.

So my plan is to use USB pass through with a linux VM. I'll use a minimal debian install with no GUI... don't think I need it. I can just run my midi software on my x-fi card in windows and pipe sound from the VM and that should work just fine, right?

Oh, and I plugged in a digital CD audio header to coax adapter and plugged it into my DAC and got beautiful audio out of my optical driver. I measured the voltage with a multimeter and I believe it is outputing 5v. I don't know if that is a problem or not, but my relatively inexpensive DAC didn't seem to mind.

So I for me to get started, I think I need to add at least two USB sound cards so I can mix the SPDIF out from my optical drive and my Orpheus sound card.

Reply 31 of 51, by darry

User metadata
Rank l33t++
Rank
l33t++
mothergoose729 wrote:

After doing some research I have some ideas. Let me know if you think this will work...

Gladly and to the best of my abilities .

mothergoose729 wrote:
I found these USB devices that are a little cheaper then the one you use and apparently that work in linux. It apparently uses t […]
Show full quote

I found these USB devices that are a little cheaper then the one you use and apparently that work in linux. It apparently uses the C-Media CM6206-LX chip... whatever that means.

https://www.amazon.com/Channel-External-Surro … 25808666&sr=8-7

A comment claims heaps of input lag but that is is in windows, I bet that has more to do with the drivers and software than the hardware. What do you think?

This is the one you linked earlier, I think.

https://www.amazon.com/Optimal-Shop-External- … 25809093&sr=8-8

I'm pretty sure that the CM6206-LX is the 5.1 version of the CM6206 (7.1). AFAIK, For digital I/O purposes, they are both equivalent as the 5.1 vs 7.1 aspect only pertains to the analogue output abilities of the chip . In fact the ones I have probably have a CM6206-LX as they are physically 5.1 on the analogue output side . Be aware, however, that some of these cheap USB sound cards have non functional optical outputs and/or inputs (in spite of the connectors being present), so reading reviews and explicitly testing whatever functionality is desired/expected upon receipt of item is recommended . These are bottom of the barrel products, IMHO, so the occasional lemon is par for the course and ordering from Amazon for easy exchange/return, if necessary, is a good idea, IMHO .

mothergoose729 wrote:

I don't think I can replicated my midi setup in linux, at least not easily. Falcosoft midi player is windows only, I am relying on some plugins from roland I don't want to fuss with, and the Roland USB midi interface could probably be made to work in linux or a similar USB adapter could work but I don't' want to do that if I can avoid it.

So my plan is to use USB pass through with a linux VM. I'll use a minimal debian install with no GUI... don't think I need it. I can just run my midi software on my x-fi card in windows and pipe sound from the VM and that should work just fine, right?

I have a few concerns with running this in a VM and would strongly recommend a dedicated machine, if possible .
a) At least with VirtualBox on Windows 10, I have never gotten audio through USB audio to work reliably even for simply playback on my Dell M4800 laptop (where I have run most of my tests) . My tests were run using a Windows XP VM (and a Windows 7 one AFAICR). So things might be different ono other hardware, with a Linux VM or with another hypervisor (VMWare or QEMU, for example) . See https://www.audiosciencereview.com/forum/inde … machines.13508/ for some more opinions on the matter .
b) Even if USB audio over passthrough can be made to work reliably for basic use on a Windows host in this use case under, I am not sure if there might be either latency or dropout issues due to potential extra overhead because of the USB passthrough .
c) Then there is concern about virtual CPU to physical CPU mapping and availability. Though this software mixer and resampler may not require a lot of CPU cycles (relatively speaking), they cannot afford to not get the CPU time it needs when they need them it or dropouts will occur . Pinning virtual CPU cores to dedicated physical ones and/or making sure the VM runs at very high priority may be necessary to get good results . How well that can be made to work with a hosted hypervisor (running under an OS like Windows) versus on a baremetal hypervisor remains to be seen/tested .

Oh and, if you want to have mixer level controls and to check for clipping using jack_mixer, you will need some kind of GUI interface . Maybe a text-based option can be made to work. Alternatively, a MIDI control surface can be made to interface with jack_mixer, for actual physical controls . Something like this https://www.amazon.ca/Korg-nanoKONTROL2-Slim- … /dp/B004M8UZS8/ would be an option (not an endorsement).

mothergoose729 wrote:

Oh, and I plugged in a digital CD audio header to coax adapter and plugged it into my DAC and got beautiful audio out of my optical driver. I measured the voltage with a multimeter and I believe it is outputing 5v. I don't know if that is a problem or not, but my relatively inexpensive DAC didn't seem to mind.

I am not surprised. My old JVC RX-6030 (or something similar), had an S/PDIF coaxial input that handled TTL level (5V ) just fine . Again, I can't speak for potential long-term issues . One safe way to get around that is to get a cheap S/PDIF coaxial to optical converter . If you can get one that tolerates 5V input and works, you will get an optical out that you can safely connect anywhere . If the converter fries, no big loss there . Whether there could be any concerns about potential harm to the CD-ROM's S/PDIF output due to potential impedance mismatch, I could not say (might be able to find an answer to that on the Internet, or maybe somebody here knows it off the top of his/her head) .

mothergoose729 wrote:

So I for me to get started, I think I need to add at least two USB sound cards so I can mix the SPDIF out from my optical drive and my Orpheus sound card.

Yes, for input . For output, you should could consider something like the Douk U2 to feed your DAC . For testing, you can probably get away with practically anything . Using multiple USB 1.1 interfaces may require the use of a multi TT USB hub, but for 2 interfaces you will probably be fine .

Reply 32 of 51, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie

Thanks Darry, I can appreciate why you think the virtual machine way is going to cause problems and I suspect you are probably correct. Nevertheless, I am going to try it first 😁. The way I see it, if I doesn't work all I have lost is time. The USB interfaces can plug into a different computer if I need do that.

I am going to get the cheaper interfaces first, because surround sound is not part of my setup and almost certainly never will be. If I get it working at the end, it will be interesting to test latency and audio quality to see what I may have lost or gained.

I ordered the two USB interfaces and I'll setup the VM. I'll send you a PM when everything comes in 😁. Super excited.

Reply 33 of 51, by darry

User metadata
Rank l33t++
Rank
l33t++
mothergoose729 wrote on 2021-07-10, 04:36:

Thanks Darry, I can appreciate why you think the virtual machine way is going to cause problems and I suspect you are probably correct. Nevertheless, I am going to try it first 😁. The way I see it, if I doesn't work all I have lost is time. The USB interfaces can plug into a different computer if I need do that.

I am going to get the cheaper interfaces first, because surround sound is not part of my setup and almost certainly never will be. If I get it working at the end, it will be interesting to test latency and audio quality to see what I may have lost or gained.

I ordered the two USB interfaces and I'll setup the VM. I'll send you a PM when everything comes in 😁. Super excited.

Your approach absolutely makes sense to me and requires minimum effort and cost to start. Additionally, it can be both fun and a learning experience, so definitely time well spent, even if it does not work as expected. I will actually try to retest USB audio in passthrough mode with VirtualBox. I might also try something along these lines https://www.qemu.org/2017/11/22/haxm-usage-windows/ .

EDIT : QEMU on a Windows host seems painfully slow, even with HAXM enabled. It is unclear, AFAIU, if USB passthrough on a Windows host even works and it does not bode that well even when running on a Linux host .

Using host USB devices on a Linux host

WARNING: this is an experimental feature. QEMU will slow down when using it. USB devices requiring real time streaming (i.e. USB Video Cameras) are not supported yet.

From https://qemu.weilnetz.de/doc/6.0/system/usb.html

Reply 34 of 51, by darry

User metadata
Rank l33t++
Rank
l33t++

@mothergoose729 and for other Windows users, this https://vb-audio.com/Voicemeeter/ might be an alternative to try .

- Presumably, the resampling quality is decent (I have not tested)
- To get the best latency, one would need to use ASIO (with ASIO4ALL, if needed), WASAPI or Kernel Streaming (all these are supported according to manual) .
- This is donationware for non professional use .

On "paper" and at first glance, this should work for the virtual audio mixer intended use case . I personally probably won't be testing a solution based on this for latency or quality because
a) what I have (Linux setup) works well enough so far
b) When I first tested the machine that I am currently running (HP Compaq 6200 Pro SFF), I was unable to get my ASM1184E PCIE switch to work under Windows 10 x64 (machine came pre-installed with it, so I just "factory reset" Windows 10 and did my initial testing), so I would have to revert to using USB audio devices and their multitudes of USB cables to test anything under Windows 10

Reply 35 of 51, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie

WASAPI is a very low latency. You can easily get down to 10ms or so of audio delay. I have seen it integrated into emulation before.

I would be willing to try it, but I'll need help verifying latency and audio quality.

Reply 36 of 51, by darry

User metadata
Rank l33t++
Rank
l33t++
mothergoose729 wrote on 2021-07-11, 17:16:

WASAPI is a very low latency. You can easily get down to 10ms or so of audio delay. I have seen it integrated into emulation before.

I would be willing to try it, but I'll need help verifying latency and audio quality.

Indeed . A fine option if running under Windows Vista or newer .

For the latency testing/latency verification aspect, I used separate machine with USB audio interface with optical input and output . My methodology for latency testing is described here Re: Not so crazy idea : using a Raspberry Pi 4 with jackd , Zita A2J bridge and jack_mixer to make a software S/PDIF mix and the audio quality test were done using RMAA. For both these tests the separate machines S/PDIF output was looked through the DUY mixer and back into the separate machine's S/PDIF input . I don't see an easy way to test without using a separate PC . Feel free to ask any questions .

On a side note, I set up a test VMWARE Player VM on my Windows 10 laptop (i7 4810MQ), gave it 2 CPUs/4GB RAM and passed through my USB Fiio E10 to the Ubuntu 21.04 guest that I was running.
I then tried to play audio with Audacity using Jack with a -p256 buffer setting (same as what I was using on a baremetal Pi4), and found that it worked, but that I got multiple skips (x-runs) . It does seem to work much better with -p 512 , but I still get the occasional skip or two while playing a track. This does not bode well for running multiple USB passthrough devices and trying to get low latency (small buffers), at least on my rather pedestrian (by today's standards) laptop . Consequently, the Windows native solution seems more promising, IMHO .

vmware_player_on_w10_audacity_playback through_jackd.png
Filename
vmware_player_on_w10_audacity_playback through_jackd.png
File size
612.15 KiB
Views
1730 views
File license
Public domain
vmware_player_on_w10_audacity_playback through_jackd_bigger_buffer.png
Filename
vmware_player_on_w10_audacity_playback through_jackd_bigger_buffer.png
File size
618.55 KiB
Views
1730 views
File license
Public domain

EDIT : -p 1024 avoids any skips, at the expense of latency :

Sun Jul 11 08:40:56 PM PDT 2021 creating alsa driver ... hw:1,0|-|1024|3|44100|0|2|nomon|swmeter|-|32bit
Sun Jul 11 08:40:56 PM PDT 2021 configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 3 periods
Sun Jul 11 08:40:56 PM PDT 2021 ALSA: final selected sample format for playback: 24bit little-endian in 3bytes format
Sun Jul 11 08:40:56 PM PDT 2021 ALSA: use 3 periods for playback
Sun Jul 11 08:41:33 PM PDT 2021 Unknown source port in attempted (dis)connection src_name [system:capture_1] dst_name [alsa-jack.jackC.4583.2:in_000]

TBH, this is still much better than what I was expecting .

EDIT2 : Further listening tests still give occasional glitches without x-run being detected .

Reply 37 of 51, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie

Thanks Darry for experimenting with VMWare. It looks like the VM route isn't totally ideal. I'll return to it if a native windows solution isn't working.

I got my USB sound cards today. They only seem to accept optical inputs so I'll have to get a few more cables and adapters. Do you know of a good way to do this with coaxial inputs without converting the signal to optical first? Each adapter is about 20$ which isn't a huge deal but it does add up.

Reply 38 of 51, by darry

User metadata
Rank l33t++
Rank
l33t++
mothergoose729 wrote on 2021-07-19, 23:20:

Thanks Darry for experimenting with VMWare. It looks like the VM route isn't totally ideal. I'll return to it if a native windows solution isn't working.

I got my USB sound cards today. They only seem to accept optical inputs so I'll have to get a few more cables and adapters. Do you know of a good way to do this with coaxial inputs without converting the signal to optical first? Each adapter is about 20$ which isn't a huge deal but it does add up.

I would guess that modding a CM6206 card to accept TTL level S/PDIF (like from a CDROM) is likely almost trivial (i.e. tap into what the toslink optical receiver would be outputting and cut power to the actual toslink receiver diode, as I presume the toslink receiver outputs either 3.3v or 5v, but I could be wrong). A cheap 5v to 3.3v level shifter may be needed (must be capable of handling S/PDIF carrier frequency which is 3MHz for 48KHz). For 1V S/PDIF, you would need additional level conversion, unless CM6206 can handle that natively .

Disclaimer: this is off the top of my head and not guaranteed to be accurate .

Reply 39 of 51, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

I've been using Pipewire for a little while now with good results. It simplifies handling of multiple audio devices and can be managed with JACK routing tools, so it would be particularly useful for this project.

All hail the Great Capacitor Brand Finder