Generic Budget USB to AES Converter Review

[alexanderino]

Also, perhaps you don't want your high-frequency signals represented by two samples (e.g. 22.05Khz signal sampled at 44.1K comprises two samples), completely throwing out all high-frequency phase information that may help spatialize audio....

We need an update to Nyquist that is also cognizant of spatialization cues and a better model of human spatialization to properly capture all aspects of human sound perception.

Interesting. Is there any study or literature that proves/supports the loss of phase at high frequencies, and/or showcases Shannon‐Nyquist's flaws?

 

[patoulol]

I have the gen 1 which sadly is broken. Anyway, it has a full galvanic isolator on the USB side which adds to the cost. It is also sold through dealers with typical high-end margin.

galvanic isolator on USB does it bring anything audible?

 

[KSTR]

galvanic isolator on USB does it bring anything audible?

Yes, it breaks those dreaded ground loops which are present in many setups (and causing a new thread every week).

 

[KSTR]

Interesting. Is there any study or literature that proves/supports the loss of phase at high frequencies, and/or showcases Shannon‐Nyquist's flaws?

There isn't. Mr. Mayer is your typical audiphile victim who does not understand the sampling theorem....

 

[KSTR]

Aliexpress USB to AES Converter Measurements
Let's start with purely digital test case. USB signal from Windows computer to digital AES input of the Audio Precision analyzer, and examining the jitter spectrum:

The lines in green (barely visible) are the spectrum of jitter when I am using Audio Precision's own AES output, going to its input using a 6 foot XLR cable. Red replaces the source with the USB to AES converter. As you see, we take a massive hit to the tune of 50 dB. Clearly there is some kind of clocking issue here.

To illustrate that this analysis went wrong, this is the spectrum of the above test with 24bit and truncation to 16bit (the J-test signal is one of the few signals that re immune to truncation by design), using not DUT at all, simply loading the generator files directly into the analyzer:

Exactly the same as with the real DUT.

The only thing we can deduce from that plot is that there is a truncation from 24 bit to 16 bit somehwere which could be anything from a simple human setup mishap to a real bug (the DUT actually receiving 24bit data via USB but truncating it to 16).

This has nothing to do with clocks, clocks aren't even involved in this test, remember this is digital loopback.
Truncation / bit-transparency would have been more easy to check with a simple bit level compare because data out must be data in, if not something is fishy. For convenience, a simple ditherered 24bit sine would do, compaing the loopback with and without DUT inserted which should be 100% identical. With DUT, one would see the typical distortion pattern of an (practically) undithered 16bit sine wave.

-------:-------

Therefore, @amirm, it would nice if you could at least change the caption below the plot to what is really happening there, a truncation rather than a clocking issue.

And the real deal would be the mentioned true jitter analysis with the AP, scanning the analog waveform of that digital output (vs. AP's one one) and looking for time irregularities, even eye-pattern etc, to really see if that adapter is putting out a totally jittery signal... which could well be of course. Sometimes engineers think they are clever by trying to achieve the exact nominal sample rates by occasionally stretching or compressing the timing. Raspberry Pi's I2S output is famous for this strategy, introducing huge amounts of jitter.

 

[patoulol]

To illustrate that this analysis went wrong, this is the spectrum of the above test with 24bit and truncation to 16bit (the J-test signal is one of the few signals that re immune to truncation by design), using not DUT at all, simply loading the generator files directly into the analyzer:
View attachment 417992
Exactly the same as with the real DUT.

The only thing we can deduce from that plot is that there is a truncation from 24 bit to 16 bit somehwere which could be anything from a simple human setup mishap to a real bug (the DUT actually receiving 24bit data via USB but truncating it to 16).

This has nothing to do with clocks, clocks aren't even involved in this test, remember this is digital loopback.
Truncation / bit-transparency would have been more easy to check with a simple bit level compare because data out must be data in, if not something is fishy. For convenience, a simple ditherered 24bit sine would do, compaing the loopback with and without DUT inserted which should be 100% identical. With DUT, one would see the typical distortion pattern of an (practically) undithered 16bit sine wave.

-------:-------

Therefore, @amirm, it would nice if you could at least change the caption below the plot to what is really happening there, a truncation rather than a clocking issue.

And the real deal would be the mentioned true jitter analysis with the AP, scanning the analog waveform of that digital output (vs. AP's one one) and looking for time irregularities, even eye-pattern etc, to really see if that adapter is putting out a totally jittery signal... which could well be of course. Sometimes engineers think they are clever by trying to achieve the exact nominal sample rates by occasionally stretching or compressing the timing. Raspberry Pi's I2S output is famous for this strategy, introducing huge amounts of jitter.

I don't understand, does that mean that this converter is not so bad after all?

 

[KSTR]

I don't understand, does that mean that this converter is not so bad after all?

There are two potential issues with it:
- there might be an unwanted and incorrect truncation to 16bit even though it was advertised as 24 bit capable
- there might a real ton of output jitter which could bring the jitter reduction quality capabilities of many DACs to the limit

Both of which might be audible in some cases.

 

[patoulol]

I have this converter, no problems listening BUT sometimes (not often), my right speaker crackles and I have to disconnect the USB converter and reconnect it for it to work

The speaker Genelec 8330 has no problem otherwise

 

[patoulol]

Yes, it breaks those dreaded ground loops which are present in many setups (and causing a new thread every week).

if it's about removing a ground loops why not just buy a Topping HS02?

 

[KSTR]

if it's about removing a ground loops why not just buy a Topping HS02?

Aftermarket add-on USB isolator to any existing device is of course an option when neither source nor receiving device have galvanic isolation and when you actually have a ground loop issue which could be solved by breaking the loop on the USB connection.

Currently, adding an USB isolator chip capable of USB 2.0 speeds to a device has only minimal impact on total cost and effort and thus manufacturers should include this in their current and future designs even if only a percentage of users will profit from it.

 

[TurtlePaul]

Interesting. Is there any study or literature that proves/supports the loss of phase at high frequencies, and/or showcases Shannon‐Nyquist's flaws?

This is not an actual issue. 22.05 khz cannot be sampled. We can only properly sample below the nyquest frequency.

At 22.05 khz the phase never rotates in the samples. At 20 khz sampled at 44.1 khz, the phase rotates 10.3% every cycle and rotates a full 360 degrees every 0.4 milliseconds. At 18 khz the phase rotates 22.5% eveey cycle and 360 degrees every 0.2 milliseconds.

 

[lashto]

The issue is that Tidal or other services now offer a lot of music at 96K and some at 192K. Playback a 192k file through a transformer and you'll get silence unless you have a player e.g. USB-Audio-Player-PRO, that allows setting the maximum sample rate for the DAC to 96K.

There's plenty of reason to want sample rates higher than nyquist frequency needed to represent 20-20Khz. For one, higher sample rates push the output filter artifacts of a DAC completely out of the audible-range and allow for a very simple, non-phase-damaging-to-human-hearing-range filter. Also, perhaps you don't want your high-frequency signals represented by two samples (e.g. 22.05Khz signal sampled at 44.1K comprises two samples), completely throwing out all high-frequency phase information that may help spatialize audio....

We need an update to Nyquist that is also cognizant of spatialization cues and a better model of human spatialization to properly capture all aspects of human sound perception.
And engineers need to stop thinking you can't perceive "imaginary numbers" and that throwing out the phase information they represent, from their frequency-domain perspective, is a scientifically valid assumption.

It would be awesome to conduct an experiment showing bats crashing into objects while echolocating, because they're wearing special headphones that digitize the sound at the corresponding Nyquist rate of bat-hearing.

+10
on top of your excellent list of reasons why 44kHz recording/playback is not enough, here's another bunch resumed from an older thread:

• 20kHz is not the highest humans can hear. Most young people hear higher and the current 'record' is 28kHz.
• a classic/acoustic orchestra produces sounds up to ~120kHz. 44kHz recording/playback just trashes an 100kHz range.
• there is a huge body of (health) research that proves how 20+kHz freqs are actually perceptible. Usually in a bad way: hearing loss, nausea, headaches etc. With the clean-sound target set at just 20kHz, many audio devices do produce a lot of 'HF-crap' .. which may be fitlered or may be not .. because "noone cares". With 192+kHz playback/recording, we (at least) get a much bigger clean range.
• there is a recent body of research from Japan that says the 'inaudible' 20-120kHz range may actually be good or even necessary.

But then, the response in that thread seems to indicate that 'everyone' is convinced that "44kHz is forever enough for everyone". Based on not sure what, since noone was able to link a study/paper/etc that says so. Looks more like an old-habits-die-hard syndrome

P.S.
it's my first post in 2025, so Happy New Year everyone!

 

[Tim Link]

Thanks for the review. This is exactly the reason I cant buy a cheap USB-> optical converter without it being measured first. We spend all that money on our gear and then cheap out on one part of the chain.

I've got a USB -> optical converter that seems pretty bad at times. But, I'm using it for the optical out of my TV, which I'm guessing is pretty bad because some receivers have difficulty locking on to it. Plus, I can't find any alternatives for the getting the optical out of the TV into my computer. Most of the time I don't hear any audible issues with it. Occasionally it causes a software freakout and I have to restart the computer.

 

[phofman]

I would not be surprised if the actual 24->16 bit truncation happened in the software before the USB transmission and the USB device reported itself as 16bit only. It would be trivial to check what formats and samplerates the device actually supports, just plug it into any linux machine (no need to have it installed, just booting from a USB flash drive) and 'cat /proc/asound/CARD_NAME/stream0'. IMO it would be useful to include such HW information with the reviews, so that real capabilites are known beforehand.

e.g. :

pavel@precision:~$ cat /proc/asound/Audio/stream0
USB Audio at usb-0000:02:00.0-4, full speed : USB Audio

Playback:
  Status: Running
    Interface = 1
    Altset = 1
    Packet Size = 200
    Momentary freq = 48000 Hz (0x30.0000)
  Interface 1
    Altset 1
    Format: S16_LE
    Channels: 2
    Endpoint: 0x01 (1 OUT) (ADAPTIVE)
    Rates: 48000
    Bits: 16
    Channel map: FL FR
  Interface 1
    Altset 2
    Format: S16_LE
    Channels: 6
    Endpoint: 0x01 (1 OUT) (ADAPTIVE)
    Rates: 48000
    Bits: 16
    Channel map: FL FR FC LFE SL SR

Capture:
  Status: Stop
  Interface 2
    Altset 1
    Format: S16_LE
    Channels: 2
    Endpoint: 0x82 (2 IN) (ASYNC)
    Rates: 48000
    Bits: 16
    Channel map: FL FR

 

[KSTR]

Yep. Linux is so extemely useful in debugging such issues that this alone fully justifies a permanent install on some older laptop one has floating around.

Alas, I have little hopes that @Amir will show any reaction and update/correct this "review", given his stance as reviewer not to dig deeper or even debug something (which is understandable, but still... :-(

 

[patoulol]

I have two USB AES converters

16/24 44khz

16/24 96khz


I have an old laptop so if someone explains the whole procedure to me I can do the verification

 

[phofman]

Just listing the device HW capabilities does not seem too much of a "digging deeper" to me, it may e.g. allow for optimal configuration of the software stack for the review (e.g. to avoid automatic resampling and sample format conversion). The fact is that USB audio devices without linux support would be disadvantaged then (and rightly so ).

 

[DrCWO]

Whether a DAC can handle this is another question but the plot shown for the D70 doesn't look nice, almost like if an improper window had been used which would suggest a brutally high jitter. And if a DAC cannot handle it, it's the DAC problem. Since @amirm doesn't test jitter reduction of DACs in his tests we have a pretty large blind spot there. Some DAC may be great (and some are known for excellent jitter reduction like the RME ADIs) and some may be bad.

Hi @amirm,
in my opinion, this hits the nail on the head!

One of the main tasks of a DAC (besides converting digital to an analog signal) is to suppress jitter in the input signal. We have seen that the otherwise excellent D70 apparently has a significant problem with this. The quality of this suppression has not been noticed in any of the DAC tests so far. I really advocate testing jitter reduction in the future.

The solution should not be to invest money in a better USB to AES converter but rather in DACs that are immune to jitter. If we do not know the quality of the jitter suppression, we leave room for discussions that some USB->AES converters and also digital cables sound better than others. This promotes HiFi voodoo!

As long as the PLL of a DAC can lock to the incoming signal and no bits get lost, a good DAC should be able to handle such a signal without degrading the analog output.

In one word: It is not the USB-ARS converter that is bad (which of course it is) but the DAC is not able to handle such a signal.

Best DrCWO

 

[DrCWO]

The only thing we can deduce from that plot is that there is a truncation from 24 bit to 16 bit somehwere which could be anything from a simple human setup mishap to a real bug (the DUT actually receiving 24bit data via USB but truncating it to 16).

Have you read that at the beginning of @amirm 's review:
"USB signal from Windows computer to digital AES input of the Audio Precision analyzer,"

Probably windows does this truncation. You are absolute right. Digging deeper to really understand what's happening here would be necessary. My expectation is that @amirm will get into it again and find out what is really happening.

 

[darth]

I believe the desire (for some of us including the person who sent the device to amir) was to convert USB to AES to feed directly into Genelecs. So adding/investing in a DAC in between probably negates that desire? Genelecs own DAC probably does the work, but that's something not upgradable.