140 for a 0404 USB? No way. The last ones went for less than half that. Their reputation for dodgy drivers is keeping prices down.
I can't say I'm very impressed with most of the usual bus-powered 2-in/2-out interfaces... dynamic range usually is somewhere in the 100-104 dB realm, distortion can be rather run of the mill. OK for recording music but hardly measurement grade.
Does anyone make a high-grade balanced receiver to connect to an unbalanced line-in these days or would you still have to roll your own, Pete Millett style? I still have a Xonar D2 floating about, close to 120 dB of input dynamic range but obviously unbalanced at consumer level. (And even dodgier drivers than Creative cards, arguably. Recently I found that for output sample rate to be set on the D1 halfway reliably, I had to use a build 1800 or older.)
You should be able to get Jan Didden's autoranger still. It gives you the balanced/unbalanced in and out and simply just works.
Here's a cheap 0404 USB if anyone is interested: E-MU EM8767 Creative 0404 USB Audio MIDI Interface | eBay
I don't get why there isn't a very simple USB ADC with decent performance available though!
Like just imagine a device like the E-MU 0404 but:
- USB bus powered
- No phantom power stuff
- Normal RCA connectors
- No pots and buttons
- No midi
- No DAC, no headphones, no optical out
etc. That would be ideal!
Like just imagine a device like the E-MU 0404 but:
- USB bus powered
- No phantom power stuff
- Normal RCA connectors
- No pots and buttons
- No midi
- No DAC, no headphones, no optical out
etc. That would be ideal!
Someone on here did design a really nice high end ADC and had a group buy. But it was expensive and complicated 🙁
An interesting option of high-end ADC is to use AK5578 with parallel operation of inputs (8->2 or even 8->1). I'm happy to check it out, I'm waiting for my digikey delivery. Just how to find the time to implement?
Legacy PCI cards run fine in latest linux and will be supported for a long time to come. Arta products run fine in wine emulator - I use it all the time.
ESI Juli was mentioned here - fully supported in linux. Asus DX2 - fully supported in linux, tested this weekend in Mint 18 based on Ubuntu 16.04 (linux kernel 4.15).
Tested also with PCI-e/PCI adapter PCI-E Express X1 to Dual PCI Riser Extend Adapter Card With USB 3.0 Cable | eBay in linux, works OK with ESI Juli, just requires clean supply instead of those noisy PSUs.
As of the missing balanced inputs which are crucial for measurements - virtual balanced inputs on these cards work just fine, in fact better than native balanced inputs since AD noise is rejected https://www.diyaudio.com/forums/pc-...ular-soundcard-linux-results.html#post5548501
The project for harmonic distortion compensation Digital Distortion Compensation for Measurement Setup is going forward, if the windows virtual cable loop proves viable it will work on windows too. Calibrated virtual balanced (and distortion-compensated) configuration will be part of the solution as it is closely related to the harmonic distortion compensation.
ESI Juli was mentioned here - fully supported in linux. Asus DX2 - fully supported in linux, tested this weekend in Mint 18 based on Ubuntu 16.04 (linux kernel 4.15).
Tested also with PCI-e/PCI adapter PCI-E Express X1 to Dual PCI Riser Extend Adapter Card With USB 3.0 Cable | eBay in linux, works OK with ESI Juli, just requires clean supply instead of those noisy PSUs.
As of the missing balanced inputs which are crucial for measurements - virtual balanced inputs on these cards work just fine, in fact better than native balanced inputs since AD noise is rejected https://www.diyaudio.com/forums/pc-...ular-soundcard-linux-results.html#post5548501
The project for harmonic distortion compensation Digital Distortion Compensation for Measurement Setup is going forward, if the windows virtual cable loop proves viable it will work on windows too. Calibrated virtual balanced (and distortion-compensated) configuration will be part of the solution as it is closely related to the harmonic distortion compensation.
EMU 0204 - is ok. Not superb, but good enough for most situations. I had it on win xp.
There is some good diy ADC: ALTOR AUDIO . I virtually know this man.
There is some good diy ADC: ALTOR AUDIO . I virtually know this man.
Last edited:
The weakness of the differential amp in the Juli@ application comes from source Z imbalance. The buffer amps in a full instrumentation amp implementation ensure equal impedances on both inputs. Even then a source impedance differential can degrade the CMRR. There is a lot written about this by THAT. Here is a link to a really good background discussion: http://www.thatcorp.com/datashts/AES6261_New_Balanced_Input_IC.pdf
A quick and effective fix would be an external balanced buffer or maybe this: THAT Corporation 626x 2-CH Digitally-Controlled Mic Preamp IC but you need an SPI interface to control it. Otherwise its would be a great fit.
I have never used the balanced in on my Juli@ cards. I have other cards which do that better but have driver interface user issues.
Thanks for the info. Actually I did not mean just the input stage, but overall chain. Cards generally tend to have conversion artifacts which are common-mode for both channels - e.g. Envy24 based cards often measure a small peak at fs/4. Potentially these artifacts are eliminated by balancing at the end of the chain, as they are on my ESI Juli.
Nevertheless this was just a note that any card can offer balanced-input setup comparable to hardware balanced inputs and if a card measures great (esp. low noise), no need to dismiss it due to lack of balanced inputs.
Nevertheless this was just a note that any card can offer balanced-input setup comparable to hardware balanced inputs and if a card measures great (esp. low noise), no need to dismiss it due to lack of balanced inputs.
I have a Steinberg ci2 I use for I/O with my basses and use that to interface with my laptop. This thread has me wondering about its suitability/compatibility with a Dayton EMM-6, as that is the mic I was considering. Hmmm.
Not USB but the new EVGA Nu Audio is pretty interesting:
EVGA - Articles - EVGA Nu Audio
They have gone all out trying attract the technical HiFi demographic with endless part names, Wima caps, PCB photos etc.
AK5572 ADC, 121dB SNR.
EVGA - Articles - EVGA Nu Audio
They have gone all out trying attract the technical HiFi demographic with endless part names, Wima caps, PCB photos etc.
AK5572 ADC, 121dB SNR.
Actually, it is a USB-based card (XMOS) with onboard PCI-e-USB controller Asmedia ASM1042. As a result it may work in linux out of the box or with just minor quirks to the existing USB-audio driver supporting other XMOS sound devices with DSD. Actually that is a very clever solution avoiding specific driver development.
I'm not sure I'd call it clever. You get none of the benefits of an actual PCIe interface.
Might as well have made a USB box if you're going to do that. At least then you don't have to open the PC to remove it.
Might as well have made a USB box if you're going to do that. At least then you don't have to open the PC to remove it.
Apart of possible lower latency, what benefits do you mean?
IMO the most important part is the controller. XMOS for USB is well tested and proven solution, supports high-samplerate PCM (384kHz), DSD256, available to companies, drivers for all OSes freely available and well tested, with future driver updates available for long time to go.
Honestly I do not know any available controller chip for PCI-e which would be available on the market for smaller companies like EVGA. Creative is proprietary. PCI-only chips with PCI-e/PCI bridge required: Envy24 (Juli XTe), Xonar (Essence STX - again proprietary for Asus) - and only 192kHz PCM, no DSD support.
IMO the only option is custom-made FPGA which is HUGE work (Lynx, RME know) + need proprietary drivers which need to be kept updated.
I would rather buy a standard USB-audio v.2 soundcard than a proprietary device where the drivers depend fully on the vendor. A new OS/kernel version comes and the hardware can be thrown away...
By using a dedicated USB controller you can guarantee the XMOS will always be the only one on the bus, no hub, no sharing, no danger of congestion etc.
PCI-e (x1) offers +12V/0.5A (and 3.3V/3A) which is much more suitable for generating clean power for the analog part than the +5V/0.5A for the whole USB soundcard. Good USB soundcards almost always need an external PSU while good PCI-e don't.
I do believe it is a clever combination.
Latency and driver performance. Just check out the DPC latency and ISR execution time for any of the USB sound cards compared to an RME or EMU PCIe card. DMA is a big advantage.
Hopefully they licensed one of the better XMOS drivers. I have a Focusrite 2i2 (XMOS) and I can make it drop samples / frames when doing system stress testing. I can't get the slightest of anything to happen with my EMU 1820m using every channel while running Cinebench, Prime95, LinX, etc. you name it.
I'm sure it works well enough, but I'd rather have it external and have a brick if needed. Your point on the power supply is definitely valid though. Just seems a bit kludgy. You're right that it's a big undertaking to create a device and write custom drivers for it for every OS. For Windows though, the driver should last a long time. Linux... well, until they break the APIs again.
Hopefully they licensed one of the better XMOS drivers. I have a Focusrite 2i2 (XMOS) and I can make it drop samples / frames when doing system stress testing. I can't get the slightest of anything to happen with my EMU 1820m using every channel while running Cinebench, Prime95, LinX, etc. you name it.
I'm sure it works well enough, but I'd rather have it external and have a brick if needed. Your point on the power supply is definitely valid though. Just seems a bit kludgy. You're right that it's a big undertaking to create a device and write custom drivers for it for every OS. For Windows though, the driver should last a long time. Linux... well, until they break the APIs again.
Last edited:
Latency and driver performance in this regard are the same. USB soundcards are not suitable for digital audio work where low latency is the key parameter. That is why I said "apart of latency". For pure playback/noninteractive recording the latency is unimportant and can be raised significantly, to the benefit of transfer robustness.
Yes, almost no peripherals would work properly without DMA. That is why USB controllers use DMA just the same way PCI(e) controllers do.
The ASM1042 PCI-e USB3 controller in that soundcard implements xHCI intel standard for USB controllers. Look at page 249 at xHCI specifications https://www.intel.com/content/dam/w...ensible-host-controler-interface-usb-xhci.pdf which describes the advanced scatter-gather DMA capabilities of the xHCI standard. Such controller requires no extra driver since it complies with the xHCI standard supported by most OSes out of the box.
The difference between PCI and USB soundcard from the software POW is actually not so large. In PCI the userspace can write audio samples directly to the memory region which the PCI sound controller reads via DMA (the direct hw:X device in linux alsa). Writing is done in chunks (period/fragment size).
For USB the userspace writes samples into an intermediary buffer and the USB-audio driver (kernel module) copies sample blocks and formats proper USB fragments (plus mixing data from other higher-level USB drivers for devices on the bus - e.g. USB drive or webcam - irrelevant on this soundcard with the dedicated USB bus) into the DMA region of the USB controller to read and send onto the bus via DMA. So there is an extra step involved - the USB uses double buffering (buffer for the userspace and DMA buffer of the USB controller with pre-prepared USB frames).
I did tests for USB-audio robustness on linux https://www.diyaudio.com/forums/pc-based/93315-linux-audio-92.html#post1719044, many years ago on ancient Duron 1GHz. USB audio can be very stable, it is all question of what size of period/buffer the driver/OS sound stack lets you configure. If your OS/driver vendor does not offer the tweaks, request a fix to get proper value for your money. Or use an OS which does not have this limitation.
Well, my experience is exactly the opposite. If the manufacturer abandons the device, its windows drivers will often not work in newer windows version.
In linux the drivers are part of the kernel source code. Almost no manufacturer supplies binary kernel modules since there is intentionally no stable ABI for kernel modules (there is a very stable ABI for user-space/kernel interface but that is a different story). Once the driver is accepted to the source tree it gets updated by the subsystem administrators for newer kernel. Throughout the years I worked on three soundcard drivers. I still use all the soundcards basically every day with the latest kernel and will use them untill PCI-e/PCI adapters become extinct. The full support for Prodigy192 was added in 2007 [ALSA] ice1724 - Functioning support for Prodigy 192 * torvalds/linux@7d4b438 * GitHub, the 6-channel card has been in my living-room HTPC for years. I use the other soundcard Infrasonic Quartet (driver written in 2009 ALSA: ice1724 - Infrasonic Quartet support * torvalds/linux@6ef8070 * GitHub) in my digital-distortion compensation project every evening. Windows 10 driver for Infrasonic is a joke Infrasonic Product Categories at infra-sonic.com
But that is offtopic to USB soundcards 🙂
Last edited: