I reported this behavior on 2.873 not the beta.
I can give remote access to the box running volumio if that will help.
I have it set, right now on DoP and it plays DSD. If I switch to Direct the dac shows PCM when playing a dsf file.
I have exactly the same behavior on v 3.063. Something is weird here… And according with volumio team our dac does not support dsd stream or quirks are not in kernel…
So strange - E30 must be powered on before RPi but otherwise just works here:
Apr 15 14:14:37 voli volumio[936]: verbose: STATE SERVICE {“status”:“play”,“position”:0,“seek”:32240,“duration”:252,“samplerate”:“2.82 MHz”,“bitdepth”:“1 bit”,“channels”:2,“random”:false,“updatedb”:false,“repeat”:false,“bitrate”:“2822 Kbps”,“isStreaming”:false,“title”:“The Art of Parties”,“artist”:“Japan”,“album”:“Tin Drum (DSD)”,“uri”:“NAS/usb1/MUSIC/Japan/Japan - 1981 - Tin Drum (Virgin-Universal Music - 5373687, 2016 HK) DSF/01 - The Art of Parties.dsf”,“trackType”:“dsf”}
Apr 15 14:14:37 voli volumio[936]: verbose: CURRENT POSITION 0
Apr 15 14:14:37 voli volumio[936]: info: CoreStateMachine::syncState stateService play
I guess no one wanted to sift through this long log. 
I really like volumio. If there is a qa team they don’t seem to really like trying to reproduce bugs.
I gave a very straightforward report of two bugs. DSD setting wrong/inverted for Topping E30 and this one. Both should be fairly straightforward to reproduce, but it seems the “QA team” prefers to pretend they are cosmic ray bugs. 
Can’t you confirm this theory from the log I provided below?
This is not the first time, but let’s make clear what is happening here, someone complains about Topping E30 not working correctly but forgets to tell on which platform. Then we get answers from people who report that E30 does work the way it is expected to, and mentions the platform he refers to (PI), and the discussion continues.
This should not have happened if it had been clear that @sritacco refers to an x86 version.
X86 has an old kernel with lots of missing quirks which we find on new kernels like the one for the PI.
These quirks, as already mentioned a few times here, are vital for proper DSD support for a specific DAC.
x86 version 2.873 has kernel version 3.18.25.
After checking the sources, I can confirm the usb audio driver does not contain a quirk for the Topping E30, so direct DSD is not supported!
Hi, but latest beta version for rpi4 should support direct dsd, because I need to set to dop in order to see dsd on my dac.
If not, any plan to be added?
Thanks
PI and X86 have different kernels, that is what I’m trying to say. The kernel for X86 is not going to be updated or patched anymore, this will be done with the introduction of Volumio 3, which supports all current DACs.
Beta: Volumiobuster-3.068-2021-04-22-x86_amd64
1 Like
Understood but what will happen with kernel for Rpi, it will support direct dsd?
I wish that question were asked up front if it’s the obvious basis for discrepancy. I provided a log. I strongly suspect the hardware info. is in three.
I don’t own a raspberry pi… Yes, it’s the current x86 image that I’ve loaded.
Also… I did do searches and didn’t find an explanation. How about adding something in a faq somewhere that clearly mentions that the Intel version doesn’t properly support a bunch of now popular DAC models and if you are having trouble with dsd try playing with the DoP settings, etc.
I did, as you can see above.
The alsa errors you see in the log are no reason to worry, they are not related to the issue you have.
(Actually, the are annoying, but not an error of any kind)
Kindly pls 2hat will happen with rpi platform, it will support dsd direct for topping e30 beta version?.
Thanks
Nothing stops you from trying a PI beta when you have a spare sd card.
Luckily with the latest kernels, not each individual DAC needs to be registered (via a quirk), if vendor ID is xmos or thesycon (or a few more), then the DAC is covered by a general quirk for all their product IDs.
I believe this quirk is in the PI kernel used for the Volumio3 PI beta, though I don’t follow PI closely enough to be sure.
Please supply the output from lsusb, then I can check and give a final answer.
Hi
001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 014: ID 152a:8750 Thesycon Systemsoftware & Consulting GmbH
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
volumio@volumio:~$
volumio@volumio:~$
Then my answer is, yes, this DAC should be fine with the existing quirks in PI kernel 5.4.83:
For people able to read it, this is the complete list of DACs supported by the general quirk:
switch (USB_ID_VENDOR(chip->usb_id)) {
case 0x152a: /* Thesycon devices */
case 0x20b1: /* XMOS based devices */
case 0x22d9: /* Oppo */
case 0x23ba: /* Playback Designs */
case 0x25ce: /* Mytek devices */
case 0x278b: /* Rotel? */
case 0x292b: /* Gustard/Ess based devices */
case 0x2972: /* FiiO devices */
case 0x2ab6: /* T+A devices */
case 0x3353: /* Khadas devices */
case 0x3842: /* EVGA */
case 0xc502: /* HiBy devices */
if (fp->dsd_raw)
return SNDRV_PCM_FMTBIT_DSD_U32_BE;
break;
default:
break;
When the DAC supports DSD direct (DSD raw), the audio driver will take care of it.
When the DAC does not support DSD direct, you will get output converted to PCM.
Thanks for this, but then why if I set dsd direct, ob my dac I see 784 pcm when play a dsd file and if I set over dop I see 5.64 MHz dsd, depends on the file. Mixer is set to hw.
Do I need to set something else?
Honestly, I don’t know.
This makes me believe that when setting is “inverted”, I should have your issue as well.
When I play this scenario here with a Khadas and Pro-ject Pre Box it works exactly as expected.
I don’t have an E30 and can’t check here.
Many thanks for your answer,
I will test again in dsd direct mode and provide some logs.
If you need special logs kindly pls tell. Me
This may help:
cat /proc/asound/card5/stream0
lsusb -t