PCM output for DSD files issues

[bernid]

Hi,
I’m trying to force MPD to convert DSD (DSF/DFF) to PCM output on two different DACs/cards connected to a Raspberry Pi 3 running DietPi Trixie. MPD works as the audio upnp renderer (with upmpdcli installed).
Both cards are configured as ALSA outputs with dsd "no" and dop "no".
However, MPD behaves differently for each and not as expected:

Case 1 – HifiBerry DAC (hw:0,0) RPI overlay (dtparam=i2s=on, dtoverlay=hifiberry-dac) and Fifo PI Q7

• MPD converts with 100% CPU load:
• output: converting in=dsd128:2 -> f=dsd128:2 -> out=384000:24:2

Case 2 – USB DAC JLsounds I2SoverUSB (hw:1,0)

• MPD ignores dsd "no" and still opens device in DSD mode:
• format=DSD_U32_BE
• output: opened "USB" (alsa) audio_format=dsd128:2

I would like MPD to always convert DSD to PCM (e.g. DSD64 → 176400:24:2, DSD128 → 352800:24:2) for playback with minimal CPU usage, without sending native DSD or DoP to ALSA.
What’s the correct configuration to force PCM output for DSD files?

Below there is a link to the file with more details:

• my MPD version,
• mpd.conf
• how debian recognise both cards,
• mpd verbose logs
• supported sample rates
  https://www.dropbox.com/scl/fi/eousv363rsbjg1sjlfvty/MPD_case.txt?rlkey=ybhg950773fvhg8t53ivyx37r&st=80ab23dz&raw=1

[borine]

read the mpd manual. Firstly, there is no such config setting dsd "no" for alsa output plugins. Secondly, to prevent mpd from selecting dsd as an output format on devices that offer it you should use the allowed_formats config setting.

The high CPU usage may also be partly caused by libsamplerate.

[bernid]

Firstly, there is no such config setting dsd "no" for alsa output plugins

Thanks, You're right. Variable dsd (yes|no) applies to pipewire, not alsa.

Secondly, to prevent mpd from selecting dsd as an output format on devices that offer it you should use the allowed_formats config setting

I've tried:

audio_output {
    type        "alsa"
    name        "fifopi_Q7"
    device      "hw:0,0"
    mixer_type  "none"
    replay_gain_handler "none"
    auto_resample "no"
    auto_channels "no"
    auto_format  "no"
    allowed_formats "176400:24:* 352800:24:* *:*:*"
}

but it didn't help and I still have:

2025-10-12T16:24:06 output: opened "fifopi_Q7" (alsa) audio_format=384000:24:2 
2025-10-12T16:24:06 libsamplerate: setting samplerate conversion ratio to 0.54 
2025-10-12T16:24:06 output: converting in=dsd128:2 -> f=dsd128:2 -> out=384000:24:2

[borine]

allowed_formats "... *:*:*"

So you have explicitly allowed all formats. Hence mpd is allowed to use dsd.

[bernid]

My goal is to play all PCM formats natively and convert DSD64 → 176400:24:2, DSD128 (and higher) → 352800:24:2. How can I achieve this?

[MaxKellermann]

but they’re still useful

No, they're not. You lost me here. I can't discuss those bogus numbers with you.

(I'm still not saying your point is wrong - but you did not post any useful data to back your claims. That's up to you.)

[bernid]

Fair point — you’re right that CPU snapshots aren’t a valid metric for profiling. Let’s set that aside. The core argument isn’t about CPU percentages, it’s about mathematical efficiency and resampling accuracy.

When converting DSD128 (5.6448 MHz → 705.6 kHz effective PCM rate):

• 352.8 kHz is an exact 2:1 ratio, meaning each pair of DSD samples maps cleanly to one PCM sample — no interpolation, no fractional resampling.
• 384 kHz requires a non-integer ratio (705.6 / 384 ≈ 1.8375), so SoX must perform a full resampling filter operation. That’s heavier computationally and introduces an extra FIR reconstruction step.

The result:
352.8 kHz = mathematically exact decimation (integer ratio).
384 kHz = fractional resample, unnecessary in this context.

That’s the essence of the “natural” argument — not load measurements, but arithmetic alignment with the original DSD clock family.
For reference, Squeezelite, HQPlayer, and JRiver all follow the same logic and convert DSD128 → 352.8 kHz for PCM output.

[MaxKellermann]

Yet more unsubstantiated claims.
Do you expect me to consider you an authority on the subject and have blind faith in your claims?

[bernid]

Thanks for clarifying the distinction between SoX and soxr — you're right, I meant soxr, not SoX.
To restate my observation more precisely:
MPD converts DSD64 to 352.8 kHz, which fits naturally within the 44.1 kHz family, but converts DSD128 to 384 kHz.
Other players (e.g. Squeezelite on the same hardware) convert both DSD64 and DSD128 to 352.8 kHz.
This difference might suggest that MPD’s rate negotiation or internal conversion logic treats DSD128 differently.
Using 352.8 kHz as the PCM target would avoid resampling to a non-integer-related rate and should, in principle, require slightly less processing.
I’m not claiming this is a bug — just noting the inconsistency for your consideration.

update:

After further testing, it looks like this behavior only occurs when MPD needs to resample.
When the DAC supports the native PCM rate directly (e.g. 352.8 kHz for DSD64), MPD picks the correct one.
But when resampling is required (e.g. DSD128 → PCM), MPD seems to fall back to the maximum available rate (384 kHz) instead of selecting the closest matching rate within the same clock family (44.1 kHz × N).

In other words, the rate negotiation logic seems to prioritize “highest supported” over “most compatible.”
This explains the difference between DSD64 and DSD128 handling and also matches what I observe in Squeezelite, which chooses 352.8 kHz in both cases.

[borine]

MPD seems to fall back to the maximum available rate (384 kHz)

That's not quite what happens. The MPD ALSA output plugin always requests the ALSA device to select its nearest supported rate to the rate of the source stream. The actual PCM sample rate for a DSD128 source is 705.6kHz. So for this device that nearest supported turns out to be its maximum rate of 384kHz. For DSD64 the source rate is 352.8 kHz so when ALSA selects its nearest supported rate on this device it gives 352.8 kHz. So there is no inconsistency here, MPD is treating both formats in exactly the same way, it's just that the ALSA device can natively handle the DSD64 rate but cannot handle the DSD128 rate.

So for DSD128 with this device it is always inevitable that resampling will be required. Squeezelite apparently chooses to set the device to a lower rate (possibly to make it an arithmetic factor of the source rate, or possibly to make it a multiple of 44.1kHZ, it is impossible to tell which from the evidence presented here). This choice may allow the resampler to apply a less CPU intensive algorithm, or it may not; that depends entirely on the resampler in use.

[bernid]

On the same hardware (RPI3+ DietPI) and track (DSD256 → PCM), forcing MPD to 352800 Hz drops CPU load from 80 % to 57 %.
The higher CPU usage at 384 kHz is not only due to the higher output rate but primarily due to the non-integer resampling ratio (11.2896 MHz → 384 kHz ≈ 29.4×), which forces a more complex interpolation filter. The integer ratio (32×) to 352.8 kHz is computationally much simpler.

384000 (default):

root@DietPi:~# pidstat -u -p $(pgrep -x mpd | head -n1) 1 60 |
awk '$NF=="mpd"{sum+=$8; n++} END{if(n) printf "Average CPU: %.2f%%\n", sum/n; else print "No data"}'
Average CPU: 80.46%

and

audio_output {
    type        "alsa"
    name        "fifopi_Q7"
    device      "hw:0,0"
#    format      "352800:*:2"
    mixer_type  "none"
    replay_gain_handler "none"
    auto_resample "no"
    auto_channels "no"
    auto_format  "no"
}

resampler {
    plugin "soxr"
    quality "high"
    threads "2"
}

352800 (temporary fixed):

root@DietPi:~# pidstat -u -p $(pgrep -x mpd | head -n1) 1 60 |
awk '$NF=="mpd"{sum+=$8; n++} END{if(n) printf "Average CPU: %.2f%%\n", sum/n; else print "No data"}'
Average CPU: 57.72%

and

audio_output {
    type        "alsa"
    name        "fifopi_Q7"
    device      "hw:0,0"
    format      "352800:*:2"
    mixer_type  "none"
    replay_gain_handler "none"
    auto_resample "no"
    auto_channels "no"
    auto_format  "no"
}

resampler {
    plugin "soxr"
    quality "high"
    threads "2"
}

[MaxKellermann]

@bernid you're still using invalid measurement methods. With your method, something that requires more compute can actually show decreased CPU usage %. Did you know that? Your numbers do not prove anything.
(Don't forget: maybe you are right, but you did not post anything demonstrating this. All the numbers you posted are useless.)

[bernid]

The purpose of the next test was to compare offline resampling DSD256 to PCM rates that are

• aligned with the source family (×44.1 kHz → 352.8 kHz) versus
• the current default maximum (×48 kHz → 384 kHz).

Currently MPD uses the maximum supported sample rate of the output device (for example 384 kHz), even when the source is from the 44.1 kHz family.
However, resampling between 44.1 kHz ↔ 48 kHz families requires a fractional conversion ratio, which is much more CPU-intensive than integer-related ratios (44.1 → 88.2 → 176.4 → 352.8).

Test setup

• Hardware: Raspberry Pi 3 B+ running DietPi
• Source: DSD256 (11.2896 MHz, stereo, bitrate ≈ 22.6 Mb/s)
• Resampler: soxr, quality "high", threads = 2
• Method: offline conversion with ffmpeg/libsoxr (identical parameters to MPD’s soxr:high preset)
• Measurement tool: /usr/bin/time
  -RTF (Real-Time Factor) = audio_duration / processing_time
  → RTF > 1 means faster than realtime.
  -CPU sec / audio sec = (user + sys) CPU time / audio_duration
  → how many CPU seconds are consumed per one second of audio.
  Lower = more efficient.

Script used:

       #!/usr/bin/env bash
set -euo pipefail
export LC_ALL=C

# === Simple DSD→PCM resampling benchmark ===
# Compares:
#   DSD → 352.8 kHz (44.1k family)
#   DSD → 384.0 kHz (48k family)
# Works for DSD128 / DSD256 (base rate >384kHz)
# Shows input sample rate and bitrate
# Adds 5s pause between runs

FILE="${1:?Please provide path to DSD file (.dsf or .dff)}"

# Get input info
IN_SR=$(ffprobe -v error -select_streams a:0 -show_entries stream=sample_rate \
         -of default=nw=1:nk=1 "$FILE")
IN_BR=$(ffprobe -v error -select_streams a:0 -show_entries format=bit_rate \
         -of default=nw=1:nk=1 "$FILE" || true)
IN_BR_KB=$(awk -v b="${IN_BR:-0}" 'BEGIN{printf "%.0f", b/1000}')

# Get duration
DUR=$(ffprobe -v error -show_entries format=duration -of default=nw=1:nk=1 "$FILE")
printf "File: %s\n" "$FILE"
printf "Input: %s Hz, bitrate ~%s kb/s\n" "$IN_SR" "$IN_BR_KB"
printf "Duration: %.2fs\n\n" "$DUR"

measure() {
  local RATE="$1"
  echo "→ Resampling to ${RATE} Hz"

  # Run ffmpeg and capture timing
  OUT=$( ( /usr/bin/time -f "elapsed=%e user=%U sys=%S" \
    ffmpeg -v error -nostats -threads 2 -i "$FILE" \
      -af aresample=resampler=soxr:osr=${RATE}:precision=28:cutoff=0.98:osf=s32 \
      -f null - 1>/dev/null ) 2>&1 )

  # Extract numbers safely
  ELAPSED=$(echo "$OUT" | awk -F'elapsed=' '{print $2}' | awk '{print $1}')
  UCPU=$(echo "$OUT" | awk -F'user=' '{print $2}' | awk '{print $1}')
  SCPU=$(echo "$OUT" | awk -F'sys=' '{print $2}' | awk '{print $1}')

  # Fallback if fields missing
  ELAPSED=${ELAPSED:-0}
  UCPU=${UCPU:-0}
  SCPU=${SCPU:-0}

  CPU=$(awk -v u="$UCPU" -v s="$SCPU" 'BEGIN{print u+s}')
  RTF=$(awk -v d="$DUR" -v e="$ELAPSED" 'BEGIN{print (e>0)? d/e : 0}')
  CPU_PER_AUDIO=$(awk -v cpu="$CPU" -v d="$DUR" 'BEGIN{print (d>0)? cpu/d : 0}')

  printf "  elapsed: %.2fs\n  user+sys: %.2fs\n  RTF: %.2fx\n  CPU-sec/audio-sec: %.3f\n\n" \
    "$ELAPSED" "$CPU" "$RTF" "$CPU_PER_AUDIO"
}

measure 352800
echo "Cooling down for 5 seconds..."
sleep 5
measure 384000

Results (DSD256 → PCM):

root@DietPi:~# bash bench_dsd_resample_simple.sh /opt/dsd256.dsf
File: /opt/dsd256.dsf
Input: 1411200 Hz, bitrate ~22579 kb/s
Duration: 107.58s

→ Resampling to 352800 Hz
  elapsed: 35.74s
  user+sys: 59.28s
  RTF: 3.01x
  CPU-sec/audio-sec: 0.551

Cooling down for 5 seconds...
→ Resampling to 384000 Hz
  elapsed: 77.45s
  user+sys: 102.74s
  RTF: 1.39x
  CPU-sec/audio-sec: 0.955

root@DietPi:~#    

Resampling to 384 kHz consumes ≈ 73 % more CPU time per second of audio
even though the target rate is only +9 % higher.
The fractional SRC (44.1 → 48 kHz) is the cause — it requires many more filter taps.

Suggestion:
Consider adding an option like:

resampler {
    plugin "soxr"
    quality "high"
    mode "source-family"    # resample to the nearest rate family (44.1 or 48 kHz)
}

That would let users choose “resample within the source rate family” instead of always upsampling to the maximum 48 kHz family rate.
This keeps DSD/44.1-based content consistent and significantly reduces CPU load on low-power clients (like RPi3), while preserving high-quality soxr conversion.