- Thread Starter
- #21
The problem does not occur on x86 architecture. I have a PC and never have such issue. On raspberry pi it’s another story.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.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.
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?
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.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.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.
# uname -a
Linux dietpi-music 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux
rpi-update should give Raspbian v4.14.94 kernel.
4.14.79 does not support native DSD.
Not sure how to update diet pi.
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.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".
sox -D orig_file.flac -t wav -C 0 -b 32 new_file.wav rate -v -s -L 705600
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:
It played just fine on my DX3 Pro, even from the NAS. The display showed "705".Code:sox -D orig_file.flac -t wav -C 0 -b 32 new_file.wav rate -v -s -L 705600
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.
It's not transmission errors. and it's not driver issue. sorry. it's softirq bug, and Linus Torvalds is aware of the bug.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."
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.
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.