Review of TRN Black Pearl: Portable USB DAC & Headphone Amp with 10-band PEQ

[sabih]

Is it possible to use NOS mode while connecting through USB port to a device such as MI TV Box?
Can anybody please confirm?
Secondly is it possible to use UAC1 mode in NOS setting?

 

[jkim]

If I understand correctly, for optimal performance, DRE would need to be dynamically adapted to the data in real time?
That means the data would need to be analyzed in real time via a buffer, and DRE would need to be adapted accordingly to the data stream?

Yes, it must be possible that way. But a bigger problem would be latency.

 

[jkim]

Does setting nos on the dac and windows usb audio output to 192k/16bit when playing 48k/16bit content perform upsampling interpolation by windows drivers or will it just output 4 times the same values to the usb dac ?

Windows upsampling (or any upsampling) includes interpolation.

Is it possible to use NOS mode while connecting through USB port to a device such as MI TV Box?

It may be 'possible.' But what kind of signal is being transmitted from the host device needs to be tested.

Secondly is it possible to use UAC1 mode in NOS setting?

I don't think the Black Pearl supports UAC1 mode. Even if it supports, oversampled audio cannot be sent in UAC1 mode due to limited bandwidth.

 

[Kevinfc]

Very thorough work, good job.

 

[CedarX]

I don't think the Black Pearl supports UAC1 mode. Even if it supports, oversampled audio cannot be sent in UAC1 mode due to limited bandwidth.

I thought UAC 1.0, the audio class, was independent from the USB speed (e.g. USB 1.0 or USB 2.0).
UAC 1.0 does limit audio signals to 24bits/96kHz, but that would still be OK for host-based upsampling, correct?

 

[jkim]

I thought UAC 1.0, the audio class, was independent from the USB speed (e.g. USB 1.0 or USB 2.0).
UAC 1.0 does limit audio signals to 24bits/96kHz, but that would still be OK for host-based upsampling, correct?

24 bit / 96 kHz is what I meant by limited bandwidth. 96 kHz is not enough for the reconstruction filtering purpose. It seems that the standard is 4x to 8x oversampling.

 

[SoySalsaPicante]

I wonder what the implication of this may be for multi-chip DACs using these Cirrus Logic decoders, such as Topping D70 Pro Octo (8 CS chips) and SMSL DO200 Pro (12 CS chips!)...

 

[Jean-Paul Petrosyan]

Hi!

If I understood what I have read correctly, DRE may also be disabled when the DAC is in a Native DSD mode. Could it be possible to test this, by any chance?

Some playback software, like Neutron MP, supports real time PCM to DSD output.

 

[jkim]

I wonder what the implication of this may be for multi-chip DACs using these Cirrus Logic decoders, such as Topping D70 Pro Octo (8 CS chips) and SMSL DO200 Pro (12 CS chips!)...

I have no reason to think these devices are immune to DRE artifacts. One can easily test if a device is affected using the C Major test clip. Search the Cirrus hump distortion thread for how-to info.

If I understood what I have read correctly, DRE may also be disabled when the DAC is in a Native DSD mode. Could it be possible to test this, by any chance?

Some playback software, like Neutron MP, supports real time PCM to DSD output.

Where did you get this information?

 

[Jean-Paul Petrosyan]

I have no reason to think these devices are immune to DRE artifacts. One can easily test if a device is affected using the C Major test clip. Search the Cirrus hump distortion thread for how-to info.


Where did you get this information?

Pages 32-35 in the CS43131 datasheet and 28-31 in the CS43198 datasheet.

But I may have misinterpreted/misattributed this. My CS43131 based device also sounds differently when playing back DSD natively (I don't seek out DSD files, but rather use PCM to DSD output option), though maybe that should be attributed to other factors.

Also, should x8 oversampling on the source's side be enough to compensate for using a "NOS" filter? I thought delta-sigma DACs oversample with much higher factors, up to x256.

 

[jkim]

Pages 32-35 in the CS43131 datasheet and 28-31 in the CS43198 datasheet.

There's no mention of a relationship b/w DSD and DRE there. In fact, I just tested the Black Pearl with a PCM-to-DSD-converted multitone signal played from the Neutron MP. The Black Pearl's LED lights up in red indicating the signal is DSD. The low-level multitone signal still distorts. Since it's DSD, NOS does not affect the result.

But I may have misinterpreted/misattributed this. My CS43131 based device also sounds differently when playing back DSD natively (I don't seek out DSD files, but rather use PCM to DSD output option), though maybe that should be attributed to other factors.

In my test said above, I noticed high-frequency distortion is added to the FFT. This seems to be consistent with what Archimago found with square waves:

Also, should x8 oversampling on the source's side be enough to compensate for using a "NOS" filter? I thought delta-sigma DACs oversample with much higher factors, up to x256.

I think there's a confusion between multi-bit/PCM oversampling and single-bit/DSD/PDM oversampling.

 

[hestejoe]

Well done. No one could ever say you forgot about DRE.

 

[Chowchilla]

I thought UAC 1.0, the audio class, was independent from the USB speed (e.g. USB 1.0 or USB 2.0).
UAC 1.0 does limit audio signals to 24bits/96kHz, but that would still be OK for host-based upsampling, correct?

If asked TRN on Ali if it supports UAC 1.0. let's see what they say

Update. Seemingly confirmed

 

[A Surfer]

I am now using an external DAC (SMSL M200) with my SMSL AO300 assuming that the built in CS chip will exhibit this distortion behavior. Not sure if the AO300 provides NOS mode?

 

[mc.god]

This NOS workaround finally gave a 2nd chance to my otherwise unused Kuang Pai Player 3 since it has very practical hardware switching to NOS and I just found a super quick way to set Pipewire (Linux Mint) at fixed 384 Khz instead of native sample rate without messing with its config file and restarting the daemon.
KP3 is not perfect in other aspects but at least It has its raison d'être now

 

[SlowLife]

Moondrop Dawn Pro has NOS mode
Press and hold +- to change filters
Normally the light will blink once when changing filters
But it will 2blinks before starting a new cycle
The 2blinks are probably NOS mode, which does not select a filter in the app

 

[jkim]

I am now using an external DAC (SMSL M200) with my SMSL AO300 assuming that the built in CS chip will exhibit this distortion behavior. Not sure if the AO300 provides NOS mode?

I think you may be one of the few who can figure that out.

I just found a super quick way to set Pipewire (Linux Mint) at fixed 384 Khz instead of native sample rate without messing with its config file and restarting the daemon.

Would you share this info?

 

[jkim]

Moondrop Dawn Pro has NOS mode
Press and hold +- to change filters
Normally the light will blink once when changing filters
But it will 2blinks before starting a new cycle
The 2blinks are probably NOS mode, which does not select a filter in the app

Can you check it? You can easily compare the NOS and standard filter's effects:

• Download the C Major test signal from here.
• Set the player software's volume to around -17 to -16 dB (use a player that supports volume control on the dB scale).
• Set your USB host device's system volume and DAC's hardware volume (if available) to max.
• Use somewhat sensitive IEM. The 7Hz x Crinacle Zero:2 worked well for me.
• Check if you hear some 'clicking' noise along with low-frequency sound in the test signal.

 

[Jean-Paul Petrosyan]

There's no mention of a relationship b/w DSD and DRE there. In fact, I just tested the Black Pearl with a PCM-to-DSD-converted multitone signal played from the Neutron MP. The Black Pearl's LED lights up in red indicating the signal is DSD. The low-level multitone signal still distorts. Since it's DSD, NOS does not affect the result.

Indeed, there's no mention of DRE there. Not anywhere in those datasheets at all, even, I believe. I thought that it might be related to the Adapt-to-Output-Signal / Class H operation mode described there, which should be disabled in Direct DSD Mode (Direct, not "Native", sorry...).

Excuse me for asking, but did you enable "Native DSD" setting in Neutron, so that it would not default to DSD-over-PCM output? My device recognizes signal as DSD either way, with an LED indicator lighting up accordingly, but I'm not sure that the processing should the same for both on the DAC's side.

Spoiler

"The DIR_DSD bit selects between two proprietary methods for DSD-to-analog conversion. The first method (DIR_ DSD =0) uses a decimation-free DSD processing technique that allows for features such as matched PCM level output, DC offset removal, DSD volume control, and 50 kHz on-chip filter. The second method (DIR_DSD = 1) sends the DSD data directly to the on-chip digital-to-analog conversion interface (without the above mentioned features). In DIR_DSD = 1 setting, the user has selection of 2 gain settings for 64•Fs and 128•Fs modes."

(p.47-50 CS43198 datasheet)

In my test said above, I noticed high-frequency distortion is added to the FFT. This seems to be consistent with what Archimago found with square waves:
View attachment 465517

Oh, I see... Interesting. Thank you very much for all this! If I'm not mistaken, the high frequency distortion levels should be OK when convertibg to DSD128 and higher, though still technically worse than with PCM. So even if it worked to get around the distortion in question, it would be an inferior option compared to using "NOS" digital filter setting, correct?

I think there's a confusion between multi-bit/PCM oversampling and single-bit/DSD/PDM oversampling.

As you can see, I'm borderline clueless when it comes to more technical details... Alas.

So would upsampling to 352 800 / 384 000 Hz in Neutron MP be enough to fully compensate for CS43131/198 "NOS" filter's effects like high frequency roll-off and high ultrasonic noise? Also, should I use Neutron's "Ultrasonic Filter" feature in this case (or in general)?

Thank you so much for your replies and your work on this matter in general! Outstanding stuff.

 

[mc.god]

Would you share this info?

Nothing obscure but I'll draw the whole context.

I have my Pipewire config file set this way

    default.clock.rate          = 44100
    default.clock.allowed-rates = [ 44100 48000 88200 96000 176400 192000 352800 384000 ]

so any sample rate to 384k is allowed and played natively if the device supports it, otherwise it's resampled to 44.1k

You can check easily with pw-top command, for example with an 88.2k file

To force 384k I'd have to change it like this

    default.clock.rate          = 384000
    default.clock.allowed-rates = [ 384000 ]

and restart pipewire daemon.

Then restore original settings and restart again to go back when it's not needed.

I simply found that you can send this command to pipewire on the fly to force a specific sample rate, say 384k:

pw-metadata -n settings 0 clock.force-rate 384000

and it sets 384k for the running session, until you restart pipewire daemon or you restore dynamic sample rate with this

pw-metadata -n settings 0 clock.force-rate Dynamic

Now, the same 88.2k file plays like this

KP3 confirms it with different led color (red for 352k and 384k, blue for 44k to 96k).

I simple saved the two commands in two sh scripts on my desktop that i can double click to execute when needed and voilà.