[GioF71]

Yes, the STX only has a different connection.
Look at the last picture of this page:

http://www.guru3d.com/articles-pages/asus-essence-stx-ii-7-1-sound-card-review,4.html

and see the adapter on the bottom right of the picture. That adapter allows you to connect a regular optical to your STX.
The plug is combined as @bcschmerker4 said.
If you want to use the optical output and do not want that adapter, you can consider buying a cable like this one:

https://www.amazon.com/Whizzotech-T...F8&qid=1499586811&sr=8-3&keywords=spdif+3.5mm

I hope the link works. This is just the first hit on amazon, I am not advising this cable against any other brand.

Anyway, both rca coaxial and optical connections can be called SPDIF: see https://en.wikipedia.org/wiki/S/PDIF

 

[GioF71]

Thank you for your help, I learn a lot with you, so if I understand correctly :

The dmp is USB connected to the U12, which is connected to the X12, and the X12 is connected to the desktop via the S / PDIF

You tell me optical, but it's S/PDIF no? I do not see any optical output

So by putting STX,1 it asks the STX not to decode, and to send in S/PDIF ? But how did you adjust the s / pdif output?

What is I2S? I have a raspberry pi, for me I2S it's the pins but there it does not look like it

Does S/PDIF not support the sampling rates of 88.2 and 176 kHz? I did not know

Here i see a review of the card : http://www.hdfever.fr/2012/02/24/test-asus-xonar-essence-stx/comment-page-6/

He say : Port S/PDIF : connexion à la carte graphique compatible via le port HDMI
It's an error, no ?

You advise me what for Deadbeef outings? I have several as indicated

It's not spdif that does not support 88.2 and 176.4. It's the digital output of my mainboard that doesn't. The STX supports all sampling rates up to 192kHz, including 88.2 and 176.4.
About "STX,1": this means the output is the digital output. If you specify STX,0, you are using the analog output (so the signal goes through the DAC).
If with "adjust" you mean how to control the volume, you can use alsamixer from the command line.

I2S is another way to transfer digital audio signal. See: https://en.wikipedia.org/wiki/I²S
This protocol separates data from clock, this results in lower jitter.
Typically you find I2S input in some DACs, for example (but not limited to) on the PS Audio, Audio-GD, Gustard, etc.
Of course you will need an interface that can output I2S. One is the Gustard U12. There are some on shenzhenaudio.com from LKS for example.

For the raspberry pi, there should be some modules to be connected to the GPIO connector.
See this implementation: http://www.audiophonics.fr/en/netwo...2s-lvds-hdmi-audio-gd-compatible-p-12031.html

About the card review: I think it is not very correct because you cannot connect some HDMI out of to the spdif out of the essence STX. The spdif connector of the essence STX is an OUTPUT connector.
But you can do something with some specific adapter:
https://www.amazon.com/ViewHD-Extractor-Optical-Converter-VHD-H2HSAs/dp/B00KBHX072
This one for example can split the hdmi out of your TV so you can decode audio through the digital input of any DAC which has an optical SPDIF input.

Please note that HDMI when transferring I2S has nothing to do with the hdmi output of the typical TV set. This has been asked multiple times. It's always hdmi, but the signal is different. If you connect the HDMI out of a TV to the HDMI I2S of an audio DAC, no sound will happen.

About Deadbeef: I do not use it currently but I have used it some time ago. I currently use MPD+upmpdcli pretty much every time I want to play back audio from my pc. If I want to play local files from my PC to the dms, I do it through a DLNA media server (rygel) pointing to my "~/Music" folder. For my music library, I have MinimServer running on my NAS.

Hope this helps!
Cheers

 

[bcschmerker4]

@Kantilo Shaxon® manufactures optical links for TOSLINK-through-RCA applications. One example is a 1m 3.5mm-to-TOSLINK, P/N POTL35M5001MBRB ($9.95 as of 9 July 2017 at Fry's Electronics®); the 3.5mm end goes to the Digital Out, and the TOSLINK end goes to a standard Optical In on another component.

 

[delooper]

Hi folks,

It's been two years now I've been playing music on my headless linux box with mpd and ALSA. Everything was going great until a system update last night. I ?suspect? the update modified some file permissions and that's caused the trouble. But I can't seem to isolate the problem.

To begin with, it appears ALSA is running fine. mplayer plays through ALSA, and speaker-test works as expected.

mpd is having troubles, though. mpd communicates with my cell phone (running MPDroid). The trouble appears to be the mpd to ALSA connection.

The first error message that appears in /var/log/mpd/mpd.log after my system update is:

zeroconf: No global port, disabling zeroconf​

Running mpd from the command line gives:

errno: failed to open log file "/var/log/mpd/mpd.log" (config line 38): Permission denied​

But permissions appear to be set appropriately for the log file (user mpd, group audio, rw access).

Similarly the mpd log file has other peculiar entries:

output: Failed to open mixer for 'USB Streamer - LX521.4'​

db: No such directory

alsa_mixer: Failed to read mixer for 'USB Streamer - LX521.4': no such mixer control: PCM​

Groups appear to be set correctly for mpd:

ps -eo user,group,supgrp,args | grep mpd
mpd audio - /usr/bin/mpd --no-daemon​

The complaints above made me wonder if perhaps the audio_output section of my mpd.conf file needs to be changed. My amixer output for my USBstreamer:

Simple mixer control 'Mic',0
Capabilities: cvolume cswitch
Capture channels: Front Left - Front Right - Rear Left - Rear Right - Front Center - Woofer - Side Left - Side Right - Rear Center - ?
Limits: Capture 0 - 255
Front Left: Capture 255 [100%] [0.00dB] [on]
Front Right: Capture 255 [100%] [0.00dB] [on]
Rear Left: Capture 255 [100%] [0.00dB] [on]
Rear Right: Capture 255 [100%] [0.00dB] [on]
Front Center: Capture 255 [100%] [0.00dB] [on]
Woofer: Capture 255 [100%] [0.00dB] [on]
Side Left: Capture 255 [100%] [0.00dB] [on]
Side Right: Capture 255 [100%] [0.00dB] [on]
Rear Center: Capture 255 [100%] [0.00dB] [on]
?: Capture 255 [100%] [0.00dB] [on]
Simple mixer control 'Mic',1
Capabilities: cvolume cvolume-joined cswitch cswitch-joined
Capture channels: Mono
Limits: Capture 0 - 255
Mono: Capture 255 [100%] [0.00dB] [on]
Simple mixer control 'USBStreamer Clock Selector',0
Capabilities: enum
Items: 'USBStreamer Internal Clock' 'USBStreamer TOSLINK Clock'
Item0: 'USBStreamer Internal Clock'
Simple mixer control 'USBStreamer Output',0
Capabilities: pvolume pswitch
Playback channels: Front Left - Front Right - Rear Left - Rear Right - Front Center - Woofer - Side Left - Side Right - Rear Center - ?
Limits: Playback 0 - 255
Mono:
Front Left: Playback 255 [100%] [0.00dB] [on]
Front Right: Playback 255 [100%] [0.00dB] [on]
Rear Left: Playback 255 [100%] [0.00dB] [on]
Rear Right: Playback 255 [100%] [0.00dB] [on]
Front Center: Playback 255 [100%] [0.00dB] [on]
Woofer: Playback 255 [100%] [0.00dB] [on]
Side Left: Playback 255 [100%] [0.00dB] [on]
Side Right: Playback 255 [100%] [0.00dB] [on]
Rear Center: Playback 255 [100%] [0.00dB] [on]
?: Playback 255 [100%] [0.00dB] [on]
Simple mixer control 'USBStreamer Output',1
Capabilities: pvolume pvolume-joined pswitch pswitch-joined
Playback channels: Mono
Limits: Playback 0 - 255
Mono: Playback 245 [96%] [-5.00dB] [on]
​

If I add

mixer_control "USBStreamer Output"

to my audio_output section of mpd.conf, the "no such mixer control: PCM" error messages are replaced with:

alsa_output: "USB Streamer - LX521.4" [alsa] failed to play: Broken pipe

changing mpd's logging to verbose there's one more clue:

alsa_mixer: Failed to read mixer for 'USB Streamer - LX521.4': no such mixer control: USBStreamer Output
​

Is there another way to specify the mixer? I'm at a loss now.

Would the remapping in my asound.conf file be causing this problem?

pcm.usbSTR {
type hw
card USBStreamer
device 0
}

pcm.usbREMAP {
type plug
slave.pcm usbSTR
ttable.0.8 1
ttable.1.9 1
}

pcm.!default {
type plug
slave.pcm usbREMAP
}

ctl.!default {
type plug
slave.pcm usbREMAP
}​

 

[chokini]

Hello,

Here is an issue I am having with gstreamer ALSA output (on Ubuntu 16.04):
the following command fails with one of my DACs (iFi Audio iDSD Nano BL)

gst-launch-1.0 filesrc location="song.flac" ! decodebin ! alsasink device=hw:1,0

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstFlacParse:flacparse0: GStreamer encountered a general stream error.
Additional debug info:
gstbaseparse.c(3599): gst_base_parse_loop (): /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstFlacParse:flacparse0:
streaming stopped, reason not-negotiated
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...

With my other DAC, the same command produces music from the flac file.
Do you have any idea about what might be going on ?

Update: this is fixed by

filesrc ! decodebin ! audioconvert ! alsasink

 

[delooper]

I think I'm zeroing-in on the source of my problems. Its starting to look like a change in alsamixer's behaviour.

alsamixer
ALSA lib dlmisc.c:254snd1_dlobj_cache_get) Cannot open shared library /usr/lib/i386-linux-gnu/alsa-lib/libasound_module_ctl_plug.so
cannot open mixer: No such device or address​

If I run alsamixer with no hardware parameters, it fails as above. If I specify the hardware device:

alsamixer -D hw:USBStreamer​

alsamixer works perfectly.

The issue with mpd is that the above error message appears in the mpd.log file, when I tell mpd.conf to use the default alsa device. . . and this appears to be the reason why mpd isn't communicating with ALSA anymore.

audio_output {
type "alsa"
name "USB Streamer - LX521.4"
}​

So my question is, can I constrain mpd to call alsamixer with a hardware parameter, to avoid this alsamixer crash?

 

[chokini]

Hello,

In MPD audio_ouput description, 'name' is a just a name given to the output.
I think you need 'device':


audio_output {
type "alsa"
name "name..."
device "hw:xyz,0" or "hw:1,0"
}

 

[delooper]

Hello,

In MPD audio_ouput description, 'name' is a just a name given to the output.
I think you need 'device':


audio_output {
type "alsa"
name "name..."
device "hw:xyz,0" or "hw:1,0"
}

Thanks, that's had some effect but it isn't enough to fix my problem. Let me show you. My audio_output:


audio_output {
type "alsa"
name "USB Streamer - LX521.4"
device "hw:USBStreamer,0"
}


Restarting mpd, the new mpd error log mpd.log:


Jan 25 02:47 : decoder_thread: probing plugin flac
Jan 25 02:47 : decoder: audio_format=44100:16:2, seekable=true
Jan 25 02:47 : alsa_output: opened hw:USBStreamer,0 type=HW
Jan 25 02:47 : alsa_output: format=S32_LE (Signed 32 bit Little Endian)
Jan 25 02:47 : alsa_output: buffer: size=12..26214 time=272..594422
Jan 25 02:47 : alsa_output: period: size=6..13107 time=136..297211
Jan 25 02:47 : alsa_output: default period_time = buffer_time/4 = 500000/4 = 125000
Jan 25 02:47 : alsa_output: buffer_size=22050 period_size=5513
Jan 25 02:47 : output: opened plugin=alsa name="USB Streamer - LX521.4" audio_format=44100:32:10
Jan 25 02:47 : output: converting from 44100:16:2
ALSA lib dlmisc.c:254:(snd1_dlobj_cache_get) Cannot open shared library /usr/lib/i386-linux-gnu/alsa-lib/libasound_module_ctl_plug.so
Jan 25 02:47 : output: Failed to open mixer for 'USB Streamer - LX521.4'


So it seems to be recognising the alsa device, but then it seems to have the same mixer problem, again.

 

[delooper]

Small progress. Here is my channel remapping in /etc/asound.conf

pcm.usbSTR {
type hw
card USBStreamer
device 0
}

pcm.usbREMAP {
type plug
slave.pcm usbSTR
ttable.0.8 1
ttable.1.9 1
}

pcm.!default {
type plug
slave.pcm usbREMAP
}

ctl.!default {
type plug
slave.pcm usbREMAP
}
​

I noticed that if I erase the ctl.!default block, alsamixer no longer crashes. Moreover, that alsamixer error from the mpd.log file goes away.

**But**, alsa does not remap the channels, i.e. I hear nothing out of my speakers. I've read that "type plug" is not allowed in ctl.!default statements in /etc/asound.conf anymore but I have not found proper documentation of this statement. It looks like I'll have to learn a little more about ALSA and how to properly perform this channel remapping.

 

[delooper]

ctl.!default {
type plug
slave.pcm usbREMAP
}
​

​

The above block seems to be a key problem with my asound.conf file. If I erase it, alsamixer loads without parameters. mpd.log no longer has alsamixer errors. Well, not of that type. Now the mpd.log errors look like:

Jan 26 01:42 : playlist: play 0:"n00s/Akashic/Conservative/Track 5.flac"
Jan 26 01:42 : decoder_thread: probing plugin flac
Jan 26 01:42 : decoder: audio_format=44100:16:2, seekable=true
Jan 26 01:42 : alsa_output: opened hw:USBStreamer,0 type=HW
Jan 26 01:42 : alsa_output: format=S32_LE (Signed 32 bit Little Endian)
Jan 26 01:42 : alsa_output: buffer: size=12..26214 time=272..594422
Jan 26 01:42 : alsa_output: period: size=6..13107 time=136..297211
Jan 26 01:42 : alsa_output: default period_time = buffer_time/4 = 500000/4 = 125000
Jan 26 01:42 : alsa_output: buffer_size=22050 period_size=5513
Jan 26 01:42 : output: opened plugin=alsa name="USB Streamer - LX521.4" audio_format=44100:32:10
Jan 26 01:42 : output: converting from 44100:16:2
Jan 26 01:42 : output: Failed to open mixer for 'USB Streamer - LX521.4'
​

If I understand the mixer complaint, I believe this means ALSA is looking for a ctl device. From what I've found, the only ctl devices that are valid are of the form

ctl.!default {
type hw
card USBStreamer
}​

well, I could set "card" to any device but it's not clear to me if there's any other options.

 

[delooper]

With my asound.conf file like this:

pcm.!default {
type plug
slave.pcm {
slave.pcm {
type hw
card USBStreamer
device 0
}
ttable.0.8 1
ttable.1.9 1
}
}​

I get no errors at all in my mpd.log file:

Jan 26 11:05 : playlist: play 0:"n00s/Akashic/Conservative/Track 5.flac"
Jan 26 11:05 : decoder_thread: probing plugin flac
Jan 26 11:05 : decoder: audio_format=44100:16:2, seekable=true
Jan 26 11:05 : alsa_output: opened hw:USBStreamer,0 type=HW
Jan 26 11:05 : alsa_output: format=S32_LE (Signed 32 bit Little Endian)
Jan 26 11:05 : alsa_output: buffer: size=12..26214 time=272..594422
Jan 26 11:05 : alsa_output: period: size=6..13107 time=136..297211
Jan 26 11:05 : alsa_output: default period_time = buffer_time/4 = 500000/4 = 125000
Jan 26 11:05 : alsa_output: buffer_size=22050 period_size=5513
Jan 26 11:05 : output: opened plugin=alsa name="USB Streamer - LX521.4" audio_format=44100:32:10
Jan 26 11:05 : output: converting from 44100:16:2
Jan 26 11:05 : state_file: Saving state file /var/lib/mpd/state​

but I also get no sound out of my speakers. Checking with alsamixer, all the levels are fine -- unchanged from when it used to work. Strangely, speaker-test no longer works:

speaker-test 1.1.0

Playback device is plughw:USBStreamer
Stream parameters are 48000Hz, S16_LE, 10 channels
Sine wave rate is 440.0000Hz
Playback open error: -16,Device or resource busy
​

But I can't seem to figure out what is making ALSA think its busy. Similarly:

aplay -D plughw:USBStreamer /usr/share/sounds/alsa/Front_Center.wav
aplay: main:722: audio open error: Device or resource busy​

Trying to discover what is making ALSA think its busy:

lsof /dev/snd/*
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/108/gvfs
Output information may be incomplete.​

 

[delooper]

sudo fuser -v /dev/snd/*
​

Showed me mpd was the culprit making ALSA busy. So I shut down the mpd service and now speaker-test works again. But mplayer is not. I thought something like:

mplayer -ao alsa:device=plughw=USBStreamer.0 *.flac
​

would play, but I'm not getting any sound.

Simplified /etc/asound.conf:

pcm.!default {
type plug
slave.pcm {
type hw
card USBStreamer
device 0
}
ttable {
0.8 1
1.9 1
}
}
​

On speaker-test, 8 is the left speaker and 9 is the right speaker.

The command "aplay -Dplughw:USBStreamer /usr/share/sounds/alsa/Rear_Center.wav" works fine.

Also "aplay -D default /usr/share/shounds/alsa/Rear_Center.wav" works as well. So it looks like my channel remapping is working.

Okay, real progress. mplayer is working too. I suppose I should have thought of this -- I had to tell it to use the default alsa device, rather than go to USBStreamer. It makes some sense as the default device is where the channel remapping is.

Next step, mpd!

I configure mpd to use the default ALSA device:

audio_output {
type "alsa"
name "USB Streamer - LX521.4"
}​

restart mpd, and it works again. This took way more time than I wanted, but I'm very happy with the outcome!

 

[111MilesToGo]

I am looking for help from the community here at Head-Fi / this particular thread. First of all, thanks to all here, your advice and communications have been enormously helpful already.

I am looking for specific help in getting Linux to play DSD natively to my Chord Hugo 2 DAC/HA. In short, what I did achieve / think to have achieved in bit-perfect manner is:

1. Windows 8.1, foobar2000 with appropriate components, Chord-supplied driver (Windows 10 pre-Creators, incl. ASIO):
   PCM, DoP and native DSD - all fine
2. Linux openSUSE Tumbleweed (KDE), Linux Mint (Cinnamon):
   PCM via stand-alone music players (DeaDBeeF, Audacious, some others)
   DoP via MPD (Music Player Daemon) and some clients (GMPC, Cantata)

At this point one can lean back and enjoy the music fully. However, the completist / perfectionist / curious person in me still is looking for how to achieve the last missing piece, native DSD to the Hugo 2 under Linux. Any help from the community is very welcome.


Now, for the long write-up.

• Chord Hugo 2:
  • Capable of accepting PCM in both 44.1 and 48 kHz series, complete up to 705.6 and 768 kHz
  • Capable of accepting native DSD64 (single), DSD128 (double), DSD256 (fourfold), DSD512 (eightfold)
  • Capable of DoP (DSD over PCM), for DSD64 to DSD256, resulting in "fake" 24/176.4, 24/352.8 and 24/705.6, resp.
    This is not stated in the Chord specs on their website / the Hugo 2 manual, but it is (a) understood for an Apple-compatible device, and (b) it was confirmed to me in an e-mail from Chord.
    For a good reference on DoP, I'd like to quote http://dsd-guide.com/dop-open-standard.

• My main Linux system is openSUSE Tumbleweed (KDE version), since it offers up-to-date software in quite a complete manner. In particular:
  • ALSA 1.1.5
    
  • MPD 0.20.16
  • GMPC 11.8.16
  • Cantata 2.2.0

According to the MPD documentation at https://www.musicpd.org/doc/user/, these building blocks should be sufficient to do native DSD output: ALSA >= 1.0.27.1, current MPD doing native DSD automatically when throwing *.dsf or *.dff DSD files at it if the receiving device is capable of it. Otherwise, DoP can be enabled in the MPD configuration file (/etc/mpd.conf).

Thus, my question seems to boil down as to whether the Hugo 2 is informing Linux / ALSA of its native DSD capability. The crucial point might be that Chord is using a custom-coded Xilinx Artix 7 chipset in the Hugo 2, i.e. not the common XMOS chipset.


Here are my diagnoses on Tumbleweed and ALSA:

aplay -l
**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: PCH [HDA Intel PCH], Gerät 0: 92HD81B1X5 Analog [92HD81B1X5 Analog]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 3: HDMI 0 [HDMI 0]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 7: HDMI 0 [HDMI 0]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 8: HDMI 0 [HDMI 0]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 9: HDMI 0 [HDMI 0]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 2: Hugo2 [Hugo2], Gerät 0: USB Audio [USB Audio]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0

aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
default
    Default ALSA Output (currently PulseAudio Sound Server)
... abridged ...
sysdefault:CARD=Hugo2
    Hugo2, USB Audio
    Default Audio Device
front:CARD=Hugo2,DEV=0
    Hugo2, USB Audio
    Front speakers
surround21:CARD=Hugo2,DEV=0
    Hugo2, USB Audio
    2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=Hugo2,DEV=0
    Hugo2, USB Audio
    4.0 Surround output to Front and Rear speakers
surround41:CARD=Hugo2,DEV=0
    Hugo2, USB Audio
    4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=Hugo2,DEV=0
    Hugo2, USB Audio
    5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=Hugo2,DEV=0
    Hugo2, USB Audio
    5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=Hugo2,DEV=0
    Hugo2, USB Audio
    7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=Hugo2,DEV=0
    Hugo2, USB Audio
    IEC958 (S/PDIF) Digital Audio Output

A script published by Ronald van Engelen (RonaldE here, thanks for it!) on https://lacocina.nl/detect-alsa-output-capabilities shows other details:

bash alsa-capabilities
... abridged ...
 6) USB Audio Class Digital alsa audio output interface `hw:2,0'
 - device name       = Hugo2                                                      
 - interface name    = USB Audio                                                  
 - usb audio class   = 2 - isochronous asynchronous                              
 - character device  = /dev/snd/pcmC2D0p                                          
 - encoding formats  = S32_LE                                                    
 - monitor file      = /proc/asound/card2/pcm0p/sub0/hw_params                    
 - stream file       = /proc/asound/card2/stream0

Now for what happens when playing music.

Here's the monitoring of the ALSA parameter and stream files during playback of a 24/192 PCM (FLAC) file:

cat /proc/asound/card2/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 192000 (192000/1)
period_size: 1024
buffer_size: 8192

cat /proc/asound/card2/stream0
Chord Electronics Ltd Hugo2 at usb-0000:26:00.0-2, high speed : USB Audio

Playback:
  Status: Running
    Interface = 2
    Altset = 1
    Packet Size = 288
    Momentary freq = 191997 Hz (0x17.ffe8)
    Feedback Format = 16.16
  Interface 2
    Altset 1
    Format: S32_LE
    Channels: 2
    Endpoint: 5 OUT (ASYNC)
    Rates: 32000, 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000, 705600, 768000
    Data packet interval: 125 us

Switching to MPD now in order to play DSD files, something the stand-alone players like DeadDBeeF or Audacious can't do.

Ronald van Engelen also provides a script to generate an MPD configuration file /etc/mpd.conf for bit-perfect playback at https://lacocina.nl/audiophile-mpd. My audio section of this file looks like

audio_output {
    type                "alsa"
    name                "Hugo2 - USB Audio"
##    device              "hw:2,0"
    device              "hw:CARD=Hugo2,DEV=0"
##    device              "iec958:CARD=Hugo2,DEV=0"
    auto_resample       "no"
    auto_format         "no"
    auto_channels       "no"
    dop                 "yes"
    replay_gain_handler "none"
    mixer_type          "none"
}
replaygain              "off"

As compared to Ronald van Engelen's script output, I have simply inserted the line
dop "yes"
in order to enable DoP playback.

And now the monitoring for playing a DSD64 (*.dsf) file via MPD in DoP mode:

cat /proc/asound/card2/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 176400 (176400/1)
period_size: 22050
buffer_size: 88200

cat /proc/asound/card2/stream0
Chord Electronics Ltd Hugo2 at usb-0000:26:00.0-2, high speed : USB Audio

Playback:
  Status: Running
    Interface = 2
    Altset = 1
    Packet Size = 272
    Momentary freq = 176404 Hz (0x16.0cf0)
    Feedback Format = 16.16
  Interface 2
    Altset 1
    Format: S32_LE
    Channels: 2
    Endpoint: 5 OUT (ASYNC)
    Rates: 32000, 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000, 705600, 768000
    Data packet interval: 125 us

When I turn off DoP in MPD, I would have expected MPD (version 0.20.16) to use native DSD automatically, but it doesn't. Instead, it seems to do an upsampled PCM, again for the DSD64 file going out as 352.8 kHz PCM:

cat /proc/asound/card2/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 352800 (352800/1)
period_size: 32768
buffer_size: 131072

cat /proc/asound/card2/stream0
Chord Electronics Ltd Hugo2 at usb-0000:26:00.0-2, high speed : USB Audio

Playback:
  Status: Running
    Interface = 2
    Altset = 1
    Packet Size = 536
    Momentary freq = 352807 Hz (0x2c.19d0)
    Feedback Format = 16.16
  Interface 2
    Altset 1
    Format: S32_LE
    Channels: 2
    Endpoint: 5 OUT (ASYNC)
    Rates: 32000, 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000, 705600, 768000
    Data packet interval: 125 us

Further remarks: I have not yet tampered with the alsa configuration files, neither pulseaudio. From the stand-alone players, I think to get as bit-perfect PCM playback as one can get.


Sorry to you, this "long write-up" has become quite long and involved.


In the end, my question to the community is: How do I get Linux (openSUSE Tumbleweed in particular) to play DSD files natively to the Chord Hugo 2, using MPD via bit-perfect ALSA? Is it possible at all?

I would also like to see what settings and alsa monitoring others folks here do get, if somebody has a DAC that does PCM and native DSD under Linux. Maybe the Oppo HA-2SE could be a suitable candidate (has an XMOS chipset).

 

[gimmeheadroom]

Hi, thanks for your post. It will take me awhile to go over it. I guess from a quick look at the mpd doc you should make sure you're using the correct protocol for DSD, one of them converts to PCM (we don't want that) and the other one uses a PCM container. That's the one we want. Check the mpd site and your config.

I have devices that support DSD 64 and 128 (and maybe higher, I have to check) but I don't have anything but small music files from the Norweigen site at the higher sampling rates. Got a bunch of SACD rips that seem to be DSD 64, still trying to figure it out.

I'll be dealing with this in the upcoming weeks and months between business trips

 

[111MilesToGo]

I am looking for specific help in getting Linux to play DSD natively to my Chord Hugo 2 DAC/HA. In short, what I did achieve / think to have achieved in bit-perfect manner is:

1. ...
2. Linux openSUSE Tumbleweed (KDE), Linux Mint (Cinnamon):
   PCM via stand-alone music players (DeaDBeeF, Audacious, some others)
   DoP via MPD (Music Player Daemon) and some clients (GMPC, Cantata)

At this point one can lean back and enjoy the music fully. However, the completist / perfectionist / curious person in me still is looking for how to achieve the last missing piece, native DSD to the Hugo 2 under Linux. Any help from the community is very welcome.

...

In the end, my question to the community is: How do I get Linux (openSUSE Tumbleweed in particular) to play DSD files natively to the Chord Hugo 2, using MPD via bit-perfect ALSA? Is it possible at all?

I would also like to see what settings and alsa monitoring others folks here do get, if somebody has a DAC that does PCM and native DSD under Linux. Maybe the Oppo HA-2SE could be a suitable candidate (has an XMOS chipset).

Well, in order to finish up on diagnosing the chain

• Linux openSUSE Tumbleweed -> MPD -> ALSA -> Chord Hugo 2,

I did look at the verbose logging from MPD for the three relevant cases.


First, playing a 24/192 PCM (FLAC) file doesn't show anything unexpected - at least to me:

Feb 19 10:52 : zeroconf: No global port, disabling zeroconf
Feb 19 10:52 : state_file: Loading state file /etc/state
Feb 19 10:52 : inotify: initializing inotify
Feb 19 10:52 : inotify: watching music directory
Feb 19 10:52 : client: [0] opened from [::1]:34694
Feb 19 10:52 : client: [0] process command "commands"
Feb 19 10:52 : client: [0] command returned 0
...
Feb 19 10:52 : client: [0] process command "playid "56""
Feb 19 10:52 : playlist: play 55:"XXX XXX XXX.flac"
Feb 19 10:52 : decoder_thread: probing plugin flac
Feb 19 10:52 : client: [0] command returned 0
Feb 19 10:52 : playlist: queue song 56:"XXX XXX XXX XXX.flac"
Feb 19 10:52 : decoder: audio_format=192000:24:2, seekable=true
...
Feb 19 10:52 : alsa_output: opened hw:CARD=Hugo2,DEV=0 type=HW
Feb 19 10:52 : alsa_output: buffer: size=48..131072 time=250..682667
Feb 19 10:52 : alsa_output: period: size=24..65536 time=125..341334
Feb 19 10:52 : alsa_output: default period_time = buffer_time/4 = 500000/4 = 125000
Feb 19 10:52 : alsa_output: format=S32_LE (Signed 32 bit Little Endian)
Feb 19 10:52 : alsa_output: buffer_size=96000 period_size=24000
Feb 19 10:52 : output: opened plugin=alsa name="Hugo2 - USB Audio" audio_format=192000:32:2
Feb 19 10:52 : output: converting in=192000:24:2 -> f=192000:24:2 -> out=192000:32:2
Feb 19 10:52 : client: [0] process command "playlistid "57""
Feb 19 10:52 : client: [0] command returned 0
...
Feb 19 10:53 : client: [0] process command "stop"
Feb 19 10:53 : playlist: stop
Feb 19 10:53 : player: played "XXX XXX XXX.flac"
Feb 19 10:53 : output: closed plugin=alsa name="Hugo2 - USB Audio"
Feb 19 10:53 : client: [0] command returned 0
...
Feb 19 10:53 : state_file: Saving state file /etc/state

Secondly, playing a DSD64 (*.dsf) file in DoP mode to the Hugo 2, i.e. with the line

dop "yes"

in the audio section of the MPD configuration file /etc/mpd.conf:

Feb 19 11:02 : client: [0] process command "playid "32""
Feb 19 11:02 : playlist: play 31:"YYY YYY YYY.dsf"
Feb 19 11:02 : decoder_thread: probing plugin dsf
Feb 19 11:02 : client: [0] command returned 0
Feb 19 11:02 : playlist: queue song 32:"YYY YYY YYY YYY.dsf"
...
Feb 19 11:02 : client: [0] process command "playlistid "32""
Feb 19 11:02 : client: [0] command returned 0
Feb 19 11:02 : decoder: audio_format=dsd64:2, seekable=true
Feb 19 11:02 : client: [0] process command "playlistid "33""
Feb 19 11:02 : client: [0] command returned 0
Feb 19 11:02 : alsa_output: opened hw:CARD=Hugo2,DEV=0 type=HW
Feb 19 11:02 : alsa_output: buffer: size=46..131072 time=260..743039
Feb 19 11:02 : alsa_output: period: size=23..65536 time=130..371520
Feb 19 11:02 : alsa_output: default period_time = buffer_time/4 = 500000/4 = 125000
Feb 19 11:02 : alsa_output: format=S32_LE (Signed 32 bit Little Endian)
Feb 19 11:02 : alsa_output: buffer_size=88200 period_size=22050
Feb 19 11:02 : alsa_output: DoP (DSD over PCM) enabled
Feb 19 11:02 : output: opened plugin=alsa name="Hugo2 - USB Audio" audio_format=dsd64:2
Feb 19 11:02 : client: [0] process command "playlistid "33""
Feb 19 11:02 : client: [0] command returned 0
...
Feb 19 11:03 : client: [0] process command "stop"
Feb 19 11:03 : playlist: stop
Feb 19 11:03 : player: played "YYY YYY YYY.dsf"
Feb 19 11:03 : output: closed plugin=alsa name="Hugo2 - USB Audio"
Feb 19 11:03 : client: [0] command returned 0

Seems fine to me. MPD/ALSA understand to use DoP, and I think the alsa output plugin does the correct selection of fake 24/176.4 PCM as the DoP "sample rate", although "176.4" don't show up literally in the MPD verbose log. I guess it is noteworthy here to realize that this DoP to the Hugo 2 at 32 bits (i.e. a 32/176.4 bit rate) does imply a 100% overhead above the bare minimum bit rate of 16/176.4 corresponding to DSD64.


Lastly, look at what happens when trying to throw native DSD at the Hugo 2, i.e. modifying the /etc/mpd.conf to be

dop "no"
or no line with dop at all, since "no" is the MPD default for the dop switch

. In this case, MPD/ALSA fall back to pure PCM at 352.8 kHz as is seen in the log:

Feb 19 11:12 : client: [0] process command "playid "34""
Feb 19 11:12 : playlist: play 33:"YYY YYY YYY.dsf"
Feb 19 11:12 : client: [0] command returned 0
Feb 19 11:12 : decoder_thread: probing plugin dsf
Feb 19 11:12 : playlist: queue song 34:"YYY YYY YYY YYY.dsf"
Feb 19 11:12 : client: [0] process command "status"
Feb 19 11:12 : client: [0] command returned 0
Feb 19 11:12 : client: [0] process command "idle"
Feb 19 11:12 : client: [0] command returned 1
Feb 19 11:12 : client: [0] process command "playlistid "34""
Feb 19 11:12 : client: [0] command returned 0
Feb 19 11:12 : decoder: audio_format=dsd64:2, seekable=true
Feb 19 11:12 : alsa_output: opened hw:CARD=Hugo2,DEV=0 type=HW
Feb 19 11:12 : alsa_output: buffer: size=90..131072 time=255..371520
Feb 19 11:12 : alsa_output: period: size=45..65536 time=127..185760
Feb 19 11:12 : alsa_output: default period_time = buffer_time/4 = 371519/4 = 92879
Feb 19 11:12 : alsa_output: format=S32_LE (Signed 32 bit Little Endian)
Feb 19 11:12 : alsa_output: buffer_size=131072 period_size=32768
Feb 19 11:12 : output: opened plugin=alsa name="Hugo2 - USB Audio" audio_format=352800:32:2
Feb 19 11:12 : output: converting in=dsd64:2 -> f=dsd64:2 -> out=352800:32:2
...
Feb 19 11:13 : client: [0] process command "stop"
Feb 19 11:13 : playlist: stop
Feb 19 11:13 : player: played "YYY YYY YYY.dsf"
Feb 19 11:13 : output: closed plugin=alsa name="Hugo2 - USB Audio"
Feb 19 11:13 : client: [0] command returned 0

My feeling now is, as underpinned by these logs:

• Either ALSA even in its latest version does not have appropriate code to output native DSD to the specific Chord Hugo 2 hardware,
• and/or the Hugo 2 does not reveal its native DSD capability appropriately to ALSA/Linux.

I am suspecting the first-mentioned item to encompass the solution, i.e. I am suspecting the ALSA folks should take care of the Hugo 2 specifics.