• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Anyone using Raspberry Pi with DX3 Pro?

OP
Y

yue

Active Member
Joined
Jul 21, 2018
Messages
275
Likes
294
I Use SK10 with Daphile 19.01-x86-rt and DSD is smooth, so it's not a kernel problem.
The problem does not occur on x86 architecture. I have a PC and never have such issue. On raspberry pi it’s another story.
 

Sangram

Member
Joined
Dec 11, 2018
Messages
49
Likes
29
The problem does not occur on x86 architecture. I have a PC and never have such issue. On raspberry pi it’s another story.

Interesting.

Not sure what I can do to help because x86 is what I mostly have. Will a RK3288-based Tinkerboard test help? There is a Volumio port for it.

I have a Zero lying around as both my Pis are on loan but that can't even manage DSD64 playback so no point testing that.

I still think it's related to the hardware deficiencies of the Pi than the kernel, but I'll take your word for it then.
 

MattG

Member
Joined
Nov 18, 2018
Messages
54
Likes
46
Does anyone use DX3 with Raspberry Pi (for instance, MPD, Rune or Volumino)? If you do, could you please check if you can play this DSD512 file smoothly?

So I just tried... Technically, it "plays", but definitely not smoothly. I get maybe half a second of sound, then half a second of silence. Music-silence-music-silence-music... So, not listenable.

Interestingly, it's the same whether I put that file on my NAS or local. Playback is via MPD. I tried setting MPD's buffer to about 80 MB (audio_buffer_size "81920"), but that didn't change anything. Looking at top while attempting playback, I saw MPD using 100% of one CPU. I have MPD parked on isolated CPUs (taskset + kernel param isolcpus), with realtime priority.

However, I don't see why it needs that much CPU... shouldn't it just be pushing the raw bits to the DX3 Pro? That I'm hitting 100% CPU suggests to me it's trying to do some kind of real-time conversion.
 
OP
Y

yue

Active Member
Joined
Jul 21, 2018
Messages
275
Likes
294
So I just tried... Technically, it "plays", but definitely not smoothly. I get maybe half a second of sound, then half a second of silence. Music-silence-music-silence-music... So, not listenable.

Interestingly, it's the same whether I put that file on my NAS or local. Playback is via MPD. I tried setting MPD's buffer to about 80 MB (audio_buffer_size "81920"), but that didn't change anything. Looking at top while attempting playback, I saw MPD using 100% of one CPU. I have MPD parked on isolated CPUs (taskset + kernel param isolcpus), with realtime priority.

However, I don't see why it needs that much CPU... shouldn't it just be pushing the raw bits to the DX3 Pro? That I'm hitting 100% CPU suggests to me it's trying to do some kind of real-time conversion.
Something is wrong on your system— probably it is trying to convert dsd to pcm. On my PI it takes only 10% of one cpu core when playing dsd natively.

Can you check whether you have other outputs enabled? For instance fifo output will always do pcm conversation. Also make sure the alsa output does not contain a “format” setting.

here's the setting I have:

audio_output {
type "alsa"
device "hw:CARD=Pro"
mixer_device "hw:CARD=Pro"
mixer_control "DX3 Pro "
name "Topping DX3 Pro"
mixer_type "hardware"
}

and I turn off all other audio_outputs and there's no audio_output_format in my config file.

You can also check the Topping DX3 Pro screen and check whether it is in DSD 512 mode. If it's showing PCM this means setting is wrong.
 
Last edited:
OP
Y

yue

Active Member
Joined
Jul 21, 2018
Messages
275
Likes
294
So I just tried... Technically, it "plays", but definitely not smoothly. I get maybe half a second of sound, then half a second of silence. Music-silence-music-silence-music... So, not listenable.

Interestingly, it's the same whether I put that file on my NAS or local. Playback is via MPD. I tried setting MPD's buffer to about 80 MB (audio_buffer_size "81920"), but that didn't change anything. Looking at top while attempting playback, I saw MPD using 100% of one CPU. I have MPD parked on isolated CPUs (taskset + kernel param isolcpus), with realtime priority.

However, I don't see why it needs that much CPU... shouldn't it just be pushing the raw bits to the DX3 Pro? That I'm hitting 100% CPU suggests to me it's trying to do some kind of real-time conversion.
I probably know why --- you didn't update the kernel so it doesn't recognize it as a native DSD capable device. If you are using vanilla Raspbian this is definately the cause. You can do a "sudo rpi-update" and a reboot. They just recently (last Dec) applied my XMOS Thesycon device id patch to the 4.14.y branch. The stock kernel provided is released last Nov.
 

MattG

Member
Joined
Nov 18, 2018
Messages
54
Likes
46
I'm using DietPi, which I believe is based on Raspbian. My DietPi system is completely up-to-date. Kernel:

Code:
# uname -a
Linux dietpi-music 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux

If this is a custom dietpi kernel, not sure what their scheme is for patch inclusion/exclusion. Is there any way to see if this running kernel has the patch?
 
OP
Y

yue

Active Member
Joined
Jul 21, 2018
Messages
275
Likes
294
rpi-update should give Raspbian v4.14.94 kernel.
4.14.79 does not support native DSD.
Not sure how to update diet pi.

there is a way to tell if your kernel support native DSD for DX3 Pro:

cat /proc/asound/Pro/stream0

and see if it has

Altset 3
Format: SPECIAL DSD_U32_BE (or LE)
 

MattG

Member
Joined
Nov 18, 2018
Messages
54
Likes
46
rpi-update should give Raspbian v4.14.94 kernel.
4.14.79 does not support native DSD.
Not sure how to update diet pi.

My DietPi is at the latest version (as of right now, v6.20.6). Looks like they are lagging Raspbian a bit. I'll just have to wait for them to pick up the newer kernel, I don't feel like hacking this guy too much.

To update DietPi, just run "dietpi-update".
 
OP
Y

yue

Active Member
Joined
Jul 21, 2018
Messages
275
Likes
294
My DietPi is at the latest version (as of right now, v6.20.6). Looks like they are lagging Raspbian a bit. I'll just have to wait for them to pick up the newer kernel, I don't feel like hacking this guy too much.

To update DietPi, just run "dietpi-update".
Yea that’s fine. An easier way to reproduce it is just trying some big pcm sample. Such as using ffmpeg or sox to upsample a 48khz audio to pcm 768khz /32bit and save it to a file then play it.
 
Last edited:

MattG

Member
Joined
Nov 18, 2018
Messages
54
Likes
46
I upsampled a 44.1kHz/16-bit file to 705.6kHz/32-bit. I did 705.6k because it's an integer multiple of 44.1k (16x). FYI, this is the command I used:
Code:
sox -D orig_file.flac -t wav -C 0 -b 32 new_file.wav rate -v -s -L 705600
It played just fine on my DX3 Pro, even from the NAS. The display showed "705".

Let me know if you'd like me to try anything else!
 
OP
Y

yue

Active Member
Joined
Jul 21, 2018
Messages
275
Likes
294
I upsampled a 44.1kHz/16-bit file to 705.6kHz/32-bit. I did 705.6k because it's an integer multiple of 44.1k (16x). FYI, this is the command I used:
Code:
sox -D orig_file.flac -t wav -C 0 -b 32 new_file.wav rate -v -s -L 705600
It played just fine on my DX3 Pro, even from the NAS. The display showed "705".

Let me know if you'd like me to try anything else!

I tried what you said. and now I have a 1:30 minutes 705.6Khz/32bit wav file (500M).

On SD card I still can hear quite a few pops per minute, but fewer than DSD512 ( why? I believe they have the same bit rate).

On NFS there are surprisingly fewer pops (probably due to I have very good wireless connection, and sd card reading interrupts may take longer than accessing NFS), but I can still hear them.

Also because there're file cache in the memory, the second time I play it, there're much fewer pops. But once I play another file and switch back in order to wipe the cache, the issue continues.
 

finneybear

Active Member
Joined
Jan 22, 2019
Messages
220
Likes
110
I tried what you said. and now I have a 1:30 minutes 705.6Khz/32bit wav file (500M).

On SD card I still can hear quite a few pops per minute, but fewer than DSD512 ( why? I believe they have the same bit rate).

On NFS there are surprisingly fewer pops (probably due to I have very good wireless connection, and sd card reading interrupts may take longer than accessing NFS), but I can still hear them.

Also because there're file cache in the memory, the second time I play it, there're much fewer pops. But once I play another file and switch back in order to wipe the cache, the issue continues.

USB protocol, at least before USB3.2, does not support error checking nor correction at the physical layer. Yes, at the physical layer, USB2.0 may have transmission errors, dropped packets, error bits, etc. The error checking and recovery will have to be done with driver/software's help.
The pops you got are most likely transmission errors (isochronous mode) and the driver does not fix them. Still driver issues.
 
OP
Y

yue

Active Member
Joined
Jul 21, 2018
Messages
275
Likes
294
USB protocol, at least before USB3.2, does not support error checking nor correction at the physical layer. Yes, at the physical layer, USB2.0 may have transmission errors, dropped packets, error bits, etc. The error checking and recovery will have to be done with driver/software's help.
The pops you got are most likely transmission errors (isochronous mode) and the driver does not fix them. Still driver issues.
It's not transmission errors. and it's not driver issue. sorry. it's softirq bug, and Linus Torvalds is aware of the bug.

also USB does have error checking feature since the earliest version. it's just usb audio spec won't force a resend when checksum mismatches inasmuch as its realtime nature. If you are copying files to external USB devices, data is guaranteed to be bit perfect.

In addition to softirq, Raspberry Pi also has a poor USB implementation. Its official documentation specially warns user against using it for audiophile purposes. See https://www.raspberrypi.org/documentation/hardware/raspberrypi/usb/README.md :

"
Devices with known issues

Expensive "audiophile" sound cards typically use far more bandwidth than is necessary to stream audio playback. Reliable operation with 96kHz/192kHz DACs is not guaranteed.
As a workaround, forcing the output stream to be CD quality (44.1kHz/48kHz 16-bit) will reduce the stream bandwidth to reliable levels."
 
Last edited:

finneybear

Active Member
Joined
Jan 22, 2019
Messages
220
Likes
110
It's not transmission errors. and it's not driver issue. sorry. it's softirq bug, and Linus Torvalds is aware of the bug.

also USB does have error checking feature since the earliest version. it's just usb audio spec won't force a resend when checksum mismatches inasmuch as its realtime nature. If you are copying files to external USB devices, data is guaranteed to be bit perfect.

In addition to softirq, Raspberry Pi also has a poor USB implementation. Its official documentation specially warns user against using it for audiophile purposes. See https://www.raspberrypi.org/documentation/hardware/raspberrypi/usb/README.md :

"
Devices with known issues

Expensive "audiophile" sound cards typically use far more bandwidth than is necessary to stream audio playback. Reliable operation with 96kHz/192kHz DACs is not guaranteed.
As a workaround, forcing the output stream to be CD quality (44.1kHz/48kHz 16-bit) will reduce the stream bandwidth to reliable levels."

This is what I meant driver issue. When the USB streaming isochronous mode starts, the receiving side will not wait for the sender. No resending hence the isochronous. On the sender side, the device driver should put the process to the high priority mode to ensure the packets are sent out in synchronous fashion otherwise there will be missing packets.

For file transfer, USB will be in the bulk mode, so called asynchronous mode. There have been some efforts to implement USB audio devices to support asynchronous mode but both XMOS and Amanero are pretty much isochronous based. In general, you need a fast CPU to stream high bit rate data smoothly. Without a highly tuned device driver, RPI just does not have enough power to do it.
 

Lucaxxaa

Member
Joined
Apr 6, 2019
Messages
19
Likes
3
Some news about rpi with volumio and topping dx3pro ? I like to try it, for play hires file by qobuz ( max flac at 24/192 )
 

Daverz

Major Contributor
Joined
Mar 17, 2019
Messages
1,294
Likes
1,451
Odd that I never noticed the noise with piCorePlayer on an RPi 3B feeding an Auralic Vega USB DAC in the speaker system. I only noticed it with the Topping D10 and the DX3Pro (LDAC version). Differences between headphone and speaker listening or differences between the USB receivers?
 

somebodyelse

Major Contributor
Joined
Dec 5, 2018
Messages
3,682
Likes
2,962
You could try recording the output of the different DACs to see if the Auralic is really free of noise. Differences in the behaviour of nominally UAC2 compliant interfaces is common enough that the linux kernel has a 'quirks' system to handle the known variations. Differences in how the DAC deals with a brief gap in data are possible too. You'd need some low level debugging tools to find out exactly what's going on.
 

Daverz

Major Contributor
Joined
Mar 17, 2019
Messages
1,294
Likes
1,451
You could try recording the output of the different DACs to see if the Auralic is really free of noise. Differences in the behaviour of nominally UAC2 compliant interfaces is common enough that the linux kernel has a 'quirks' system to handle the known variations. Differences in how the DAC deals with a brief gap in data are possible too. You'd need some low level debugging tools to find out exactly what's going on.

I have a spare headphone amp I can hook up to the Auralic to check if I'm just missing the noise on speakers. Also I'm using an RPi 3B on the Auralic; the DX3 is hooked up to a 3B+, but both are running piCorePlayer 5.0.0.

Right now I'm running squeezelite on a linux PC connected to the D3X. I've tested with DSD64, 192K and 352.8K files, and no pop or blip noises.

I'm really disappointed that the RPi (and apparently linux on ARM?) has this issue. Some of the "clean USB" products such as the Allo USBridge cost as much as the DX3pro itself.

https://allo.com/sparky/usbridge-signature-pcb.html
 

somebodyelse

Major Contributor
Joined
Dec 5, 2018
Messages
3,682
Likes
2,962
The Pi 4 doesn't have this problem so far as I can tell. I reran a test situation that reliably causes glitches for me when run on a 3B+ and had no glitches with the 4. This was pretty much expected due to the hardware changes in the 4 - it has true separate USB host ports and gigabit ethernet connected via PCIe instead of a single USB-OTG port that's shared by all 4 usb sockets and the usb ethernet adapter.

It's not a linux on ARM problem, but the prevalence of USB-OTG ports on ARM CPUs makes it more likely as the driver for the OTG port has to do in software some of the bits that are done in hardware by true host ports. I don't see how the Allo USBridge would solve this as so far as i can tell it's using the same USB-OTG port as other Pis <4.
 

Daverz

Major Contributor
Joined
Mar 17, 2019
Messages
1,294
Likes
1,451
The Pi 4 doesn't have this problem so far as I can tell. I reran a test situation that reliably causes glitches for me when run on a 3B+ and had no glitches with the 4. This was pretty much expected due to the hardware changes in the 4 - it has true separate USB host ports and gigabit ethernet connected via PCIe instead of a single USB-OTG port that's shared by all 4 usb sockets and the usb ethernet adapter.

It's not a linux on ARM problem, but the prevalence of USB-OTG ports on ARM CPUs makes it more likely as the driver for the OTG port has to do in software some of the bits that are done in hardware by true host ports. I don't see how the Allo USBridge would solve this as so far as i can tell it's using the same USB-OTG port as other Pis <4.

Thanks for the comments. I guess it's time to see how piCorePlayer 6.0 beta is coming along on RPi 4.

I've heard that the Pi4 runs hotter. Is this a problem when just running squeezelite?
 
Last edited:
Top Bottom