2017-02-25 23:41 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0003900MPDMPDpublic2017-02-10 15:04
Reporterconta 
Assigned Tocirrus 
PrioritynormalSeverityfeatureReproducibilityalways
StatusresolvedResolutionduplicate 
PlatformLinuxOSLubuntuOS Version13.10
Product Versiongit 
Target VersionFixed in Versiongit 
Summary0003900: Reduce output thread latency for DSD128 on Atom CPU
DescriptionIt seems, that DSD128 and DSD-Multichannel are not working as they should. DSD64 plays back perfectly.
Strange thing: While playing a DSD128/DSD-multichannel-file, the display of the AVR is flickering like mad. Unfortunately its too fast to see between which states it is switching so fast.
Steps To ReproducePut a DSD128/DSD-multichannel-file in the database and try to play it.
TagsNo tags attached.
Attached Files

-Relationships
duplicate of 0003081closedcirrus soft clicking sounds appearing during the playback 
+Relationships

-Notes

~0008102

ranperry (reporter)

DSD128 works fine for me. Anything shows up in the logs?

~0008103

conta (reporter)

It seems the following lines from the verbose-log-file cause the trouble:

Dec 08 23:07 : alsa_output: Underrun on ALSA device "hw:0,3"
Dec 08 23:07 : alsa_output: Underrun on ALSA device "hw:0,1"

I have following setup:
hw:0,3 is HDMI and
hw:0,1 is SPDIF.

I tried it also without SPDIF -> same reaction.

~0008104

ranperry (reporter)

Do you get this all the time while playing DSD128 files or at random times? Also, do you run your files locally or from a NAS? I am having the same problem with the underruns and I cannot point my finger at the cause. What happens if you only use SPDIF? does it happen as well?

~0008106

conta (reporter)

Last edited: 2013-12-09 14:56

View 2 revisions

I run the files from the local hdd and i get this behaviour always.
I did not test SPDIF-alone but i'm quite sure, that it will be the same - i will test it.
It should not be a problem with the bitrate - 5.1 with 24bit/96kHz or even 24bit/384kHz in stereo is no problem here.
Do you know which bitrate the DSD128-output has?

hmmm - Maybe the hardware is too slow for converting DSD -> PCM in higher rates? It's only a Atom330.

EDIT:
Well, just tested the SPDIF-interface -> here i got sound, but extremely stuttering. So i would say it's the same signal like at the HDMI-port, but a DAC slightly less sensitive.
For the hardware: DSD64-stereo needs about 50% of the CPU-power. And it seems, that the other signals (DSD128, DSD-multichannel) do not need that much more, also between 50 and 55%.
So CPU-power is not the crucial-point it seems.

~0008112

ranperry (reporter)

What id your DSD DAC? Based on your CPU usage, it looks like you are not using DoP. Can you post your output from the conf file?

~0008113

conta (reporter)

I'm not using DoP. The DAC is a MusicalFidelity V-DAC.
How does DSD128/multichannel work at your System without DoP?

~0008114

ranperry (reporter)

I do not use multichannel only 2 channels DSD64 and DSD128. If I do not use DoP, MPD will upsample DSD to 384Khz and this very CPU intensive process.

~0008119

conta (reporter)

I think, we have a very similar setting. Strange, that you don't have problems with DSD128?
This is the output-part of my mpd.conf:

audio_output {
    type "alsa"
    name "HDMI"
    device "hw:0,3" # optional
    always_on "no"
# format "44100:16:2" # optional
# mixer_type "software" # optional
# mixer_device "default" # optional
# mixer_control "PCM" # optional
# mixer_index "0" # optional
}
#
audio_output {
    type "alsa"
    name "SPDIF"
    device "hw:0,1" # optional
# format "44100:16:2" # optional
# mixer_type "software" # optional
# mixer_device "default" # optional
# mixer_control "PCM" # optional
# mixer_index "0" # optional
}

~0008120

ranperry (reporter)

What is "always_on"? This is my output:

audio_output {
        type "alsa"
        name "Wyred4Sound"
        device "hw:CARD=Interface,DEV=0"
    use_mmap "yes" # added recently to see if it improves performance
    dsd_usb "yes" # this enables DoP for DSD enabled DACs
    mixer_type "disabled"
}

~0008122

conta (reporter)

Last edited: 2013-12-11 14:34

View 3 revisions

When other software runs on the pc, MPD should not block the alsa-port. This is ment with " alway_on "no" ". Maybe it is set to "no" per default? I don't know.
Your line "use_mmap" is interresting - i will try it, maybe it makes the difference?!

EDIT:
ok, just tested with your settings --> no difference!

Could you maybe test it without DoP? Possibly you got the same problems like i have?

~0008148

cirrus (administrator)

I don't get it. What is this bug report about? You did not describe what exactly does not work, and how you expect it to be instead.

~0008152

conta (reporter)

Sorry, my english is not the best. When it helps, i can describe the problem in german language.

The thing is, when DSD128-files or DSD-multichannel-files (*.dsf) are played back over the alsa interface, it comes to an alsa-buffer-underrun (documented in the log-file). This leads to a VERY stuttering output of the DAC, conected to the SPDIF-port, and a flickering display and NO output of the AVR, conected to the HDMI-port.
At least here on my PC. User ranperry does not have these problems, but he uses the DoP-protocol, which i don't use.

~0008162

cirrus (administrator)

Paste a verbose log of playback start until after a few underruns have occurred. And say which version of MPD exactly you're using. If you really use a git version, specify which commit id.

~0008163

conta (reporter)

OK, the command "mpd --version" gives me: Music Player Daemon 0.19~git.
I hope this is the commit id?!
And the verbose-log looks like this:


Dec 20 19:07 : client: [0] process command "currentsong"
Dec 20 19:07 : client: [0] command returned 0
Dec 20 19:07 : client: [0] process command "status"
Dec 20 19:07 : client: [0] command returned 0
Dec 20 19:07 : client: [0] process command "play "-1""
Dec 20 19:07 : playlist: play 0:"_test/2L - test/2L-050_stereo-DSD128_01.dff"
Dec 20 19:07 : client: [0] command returned 0
Dec 20 19:07 : decoder_thread: probing plugin dsdiff
Dec 20 19:07 : decoder: audio_format=705600:dsd:2, seekable=false
Dec 20 19:07 : alsa_output: opened hw:0,3 type=HW
Dec 20 19:07 : alsa_output: format=S32_LE (Signed 32 bit Little Endian)
Dec 20 19:07 : alsa_output: buffer: size=32..8192 time=166..42667
Dec 20 19:07 : alsa_output: period: size=16..4096 time=83..21334
Dec 20 19:07 : alsa_output: default period_time = buffer_time/4 = 42666/4 = 10666
Dec 20 19:07 : alsa_output: buffer_size=8192 period_size=2048
Dec 20 19:07 : libsamplerate: setting samplerate conversion ratio to 0.27
Dec 20 19:07 : output: opened plugin=alsa name="HDMI" audio_format=192000:32:2
Dec 20 19:07 : output: converting from 705600:dsd:2
Dec 20 19:07 : alsa_output: opened hw:0,1 type=HW
Dec 20 19:07 : alsa_output: format=S32_LE (Signed 32 bit Little Endian)
Dec 20 19:07 : alsa_output: buffer: size=32..8192 time=333..85334
Dec 20 19:07 : alsa_output: period: size=16..4096 time=166..42667
Dec 20 19:07 : alsa_output: default period_time = buffer_time/4 = 85333/4 = 21333
Dec 20 19:07 : alsa_output: buffer_size=8192 period_size=2048
Dec 20 19:07 : libsamplerate: setting samplerate conversion ratio to 0.14
Dec 20 19:07 : output: opened plugin=alsa name="SPDIF" audio_format=96000:32:2
Dec 20 19:07 : output: converting from 705600:dsd:2
Dec 20 19:07 : client: [0] process command "status"
Dec 20 19:07 : client: [0] command returned 0
Dec 20 19:07 : client: [0] process command "playlistinfo "-1""
Dec 20 19:07 : client: [0] command returned 0
Dec 20 19:07 : client: [0] process command "currentsong"
Dec 20 19:07 : client: [0] command returned 0
Dec 20 19:07 : alsa_output: Underrun on ALSA device "hw:0,3"
Dec 20 19:07 : alsa_output: Underrun on ALSA device "hw:0,1"
Dec 20 19:07 : alsa_output: Underrun on ALSA device "hw:0,3"
Dec 20 19:07 : alsa_output: Underrun on ALSA device "hw:0,3"
Dec 20 19:07 : alsa_output: Underrun on ALSA device "hw:0,3"
Dec 20 19:07 : alsa_output: Underrun on ALSA device "hw:0,1"
Dec 20 19:07 : alsa_output: Underrun on ALSA device "hw:0,3"
Dec 20 19:07 : alsa_output: Underrun on ALSA device "hw:0,3"
Dec 20 19:07 : alsa_output: Underrun on ALSA device "hw:0,1"
Dec 20 19:07 : alsa_output: Underrun on ALSA device "hw:0,3"
Dec 20 19:07 : alsa_output: Underrun on ALSA device "hw:0,3"
Dec 20 19:07 : alsa_output: Underrun on ALSA device "hw:0,1"


I hope you can see something between the lines! :-)

~0008164

msmucr (reporter)

Last edited: 2013-12-20 19:58

View 2 revisions

Hi Conta,
my guess is that your Atom simply doesn't have enough juice to convert DSD on-the-fly. I have NUC with Celeron 847 (faster CPU than Atom 330) and DSD128 also won't play without glitches, DSD64 is lighter on calculation and plays fine.
 
You could see details of conversion in your verbose log, DSD stream rate is first converted by fixed ratio 8:1 to 705,600kHz and then by libsamplerate converter to maximum output rate of your SPDIF interface - 96kHz and HDMI interface - 192kHz. In your case to both simultaneously.
To prove CPU power issues, disable one unused output (either in your MPD client or in config) to save one unnecessary conversion, play file again and check CPU usage of MPD process during playback. You could use top utility for that.

Aside from this, you'll got better DSD->PCM conversion quality by using external offline tool like KORG AudioGate (works great for stereo DSD to FLAC conversion).

~0008165

cirrus (administrator)

Yes, this very much looks like saturated CPU. You feed data into two ALSA outputs. Each requires a DSD to PCM conversion, and each requires a resampler. Both consumes a lot of CPU. And your CPU may be too weak for this.

Can you demonstrate that your CPU is not saturated? Or is our theory correct?

~0008166

conta (reporter)

Thanks a lot for your suggestions!
I disabled the SPDIF-outout in the mpd.conf and had a sharp look at the CPU-usage shown at the taskmanager in Lubuntu:
PCM: 1%
DSD64: 18%
DSD128: 26%

With both outputs (HDMI + SPDIF) the CPU-usage looks like that:
PCM: 1%
DSD64: 39%
DSD128: 48%

First i thoght its maybe a problem with the Dual-core CPU (MPD maybe runs only on one core?), but it seems that there is another problem. DSD128 (HDMI only) with 26% cannot be played but DSD64 (HDMI+SPDIF) with 39% plays flawlessly.
Can i do some other measurement to help you?

Thank you for the hint with the DSD2PCM-software - i'm aware of Korg and also Saracon. But i don't want to convert my DSD-files, i still have the hope, that someday it will be possible to playback DSD just normal over HDMI. And on the other hand more and more DoP-DAC's are popping out. Maybe someday there will be one for DSD-multichannel at a reasonabel price?

~0008167

msmucr (reporter)

Low CPU usage numbers, you're reaching, are bit suspicious to me for your CPU model. I've never achieved it with default libsamplerate converter settings, assuming either have defined samplerate_converter "0" in your config or there is no such definition.
Maybe there is different reading of process CPU usage in Ubuntu taskmanager, try to open terminal and use command top instead. Processes are sorted by CPU usage by default, so during playback mpd process should be at top of process list. Check its usage peaks, if there will be 100% peaks during underruns, it is possible problem.

I saw, you're running git version, did you compiled mpd from latest source by yourself? I'm asking because, if so, i'll post you further instructions for building latest mpd with soxr library, which is much more efficient than default libsamplerate and could help you with stuttering, if it is due to CPU constrains.

~0008168

cirrus (administrator)

So, does playback work with only one output enabled?

The CPU usage you cited, is this the average usage of both CPU cores or just the usage of one core?

~0008170

conta (reporter)

@cirrus:

No, playback does never work for DSD128.
The given output of the taskmanager should be the CPU-usage of both cores together, means the CPU-usage of the whole system.

@msmucr:
I tried to use the top-command, but i get crazy results like 170%. For any reason top seems to work incorrect on my system?!
You are right - i use the git-version, but i don't compile it for myselfe (to be honest: i don't know how to do that...), but take the version from the repository.
What CPU-usage do you have on your NUC when playing DSD64/DSD128?

~0008171

cirrus (administrator)

Ok, then this is an internal latency issue, not a saturated CPU.

On one output, the period_time is 10ms, and the other has 20ms. This means that MPD must push new data to the device 100 times a second - which is a difficult requirement. The ring buffer in the driver/chip is very small, and if the sample rate is so high, there can be problems.

This is something that should be optimized inside MPD. It should be possible for MPD to fullfill that, as long as the CPU is not saturated.

~0008172

cirrus (administrator)

Try adding the following to your mpd.conf:

audio_output_format "*:32:*"

See if that solves your problem, report here. Then change to:

audio_output_format "96000:32:*"

And then to:

audio_output_format "96000:16:*"

Please report what you observed for each configuration, and paste a short verbose log of playback start.

~0008176

conta (reporter)

Last edited: 2013-12-22 00:34

View 2 revisions

Well,
I put the lines in the audio-output section, i hope, thats the right place?!
With all 3 lines there is no difference --> no sound.
BUT, when i do not use your 3 lines, but activate the line:
format "44100:16:2"
things get better. It is possible to hear the sound, but there is still some stuttering. Much better, then hearing nothing! :-)
Following are the verbose-logs:

44100:16:2

ec 21 23:47 : playlist: play 0:"_test/2L - test/2L-050_stereo-DSD128_01.dff"
Dec 21 23:47 : client: [0] command returned 0
Dec 21 23:47 : decoder_thread: probing plugin dsdiff
Dec 21 23:47 : decoder: audio_format=705600:dsd:2, seekable=false
Dec 21 23:47 : alsa_output: opened hw:0,3 type=HW
Dec 21 23:47 : alsa_output: format=S16_LE (Signed 16 bit Little Endian)
Dec 21 23:47 : alsa_output: buffer: size=64..16384 time=1451..371520
Dec 21 23:47 : alsa_output: period: size=32..8192 time=725..185760
Dec 21 23:47 : alsa_output: default period_time = buffer_time/4 = 371519/4 = 92879
Dec 21 23:47 : alsa_output: buffer_size=16384 period_size=4096
Dec 21 23:47 : libsamplerate: setting samplerate conversion ratio to 0.06
Dec 21 23:47 : output: opened plugin=alsa name="HDMI" audio_format=44100:16:2
Dec 21 23:47 : output: converting from 705600:dsd:2
Dec 21 23:47 : client: [0] process command "status"
Dec 21 23:47 : client: [0] command returned 0
Dec 21 23:47 : client: [0] process command "playlistinfo "-1""
Dec 21 23:47 : client: [0] command returned 0
Dec 21 23:47 : client: [0] process command "currentsong"
Dec 21 23:47 : client: [0] command returned 0
Dec 21 23:47 : client: [0] process command "status"
Dec 21 23:47 : client: [0] command returned 0
Dec 21 23:47 : client: [0] process command "playlistinfo "-1""
Dec 21 23:47 : client: [0] command returned 0
Dec 21 23:47 : client: [0] process command "currentsong"
Dec 21 23:47 : client: [0] command returned 0
Dec 21 23:47 : client: [0] process command "status"
Dec 21 23:47 : client: [0] command returned 0
Dec 21 23:47 : client: [0] process command "playlistinfo "-1""
Dec 21 23:47 : client: [0] command returned 0
Dec 21 23:47 : client: [0] process command "currentsong"
Dec 21 23:47 : client: [0] command returned 0
Dec 21 23:47 : alsa_output: Underrun on ALSA device "hw:0,3"
Dec 21 23:47 : client: [0] process command "status"

*:32:*

Dec 22 00:18 : playlist: play 0:"_test/2L - test/2L-050_stereo-DSD128_01.dff"
Dec 22 00:18 : client: [0] command returned 0
Dec 22 00:18 : decoder_thread: probing plugin dsdiff
Dec 22 00:18 : decoder: audio_format=705600:dsd:2, seekable=false
Dec 22 00:18 : alsa_output: opened hw:0,3 type=HW
Dec 22 00:18 : alsa_output: format=S32_LE (Signed 32 bit Little Endian)
Dec 22 00:18 : alsa_output: buffer: size=32..8192 time=166..42667
Dec 22 00:18 : alsa_output: period: size=16..4096 time=83..21334
Dec 22 00:18 : alsa_output: default period_time = buffer_time/4 = 42666/4 = 10666
Dec 22 00:18 : alsa_output: buffer_size=8192 period_size=2048
Dec 22 00:18 : libsamplerate: setting samplerate conversion ratio to 0.27
Dec 22 00:18 : output: opened plugin=alsa name="HDMI" audio_format=192000:32:2
Dec 22 00:18 : output: converting from 705600:dsd:2
Dec 22 00:18 : client: [0] process command "status"
Dec 22 00:18 : client: [0] command returned 0
Dec 22 00:18 : client: [0] process command "playlistinfo "-1""
Dec 22 00:18 : client: [0] command returned 0
Dec 22 00:18 : client: [0] process command "currentsong"
Dec 22 00:18 : client: [0] command returned 0
Dec 22 00:18 : alsa_output: Underrun on ALSA device "hw:0,3"
Dec 22 00:18 : alsa_output: Underrun on ALSA device "hw:0,3"

96:32:*

Dec 22 00:19 : playlist: play 0:"_test/2L - test/2L-050_stereo-DSD128_01.dff"
Dec 22 00:19 : client: [0] command returned 0
Dec 22 00:19 : decoder_thread: probing plugin dsdiff
Dec 22 00:19 : decoder: audio_format=705600:dsd:2, seekable=false
Dec 22 00:19 : alsa_output: opened hw:0,3 type=HW
Dec 22 00:19 : alsa_output: format=S32_LE (Signed 32 bit Little Endian)
Dec 22 00:19 : alsa_output: buffer: size=32..8192 time=333..85334
Dec 22 00:19 : alsa_output: period: size=16..4096 time=166..42667
Dec 22 00:19 : alsa_output: default period_time = buffer_time/4 = 85333/4 = 21333
Dec 22 00:19 : alsa_output: buffer_size=8192 period_size=2048
Dec 22 00:19 : libsamplerate: setting samplerate conversion ratio to 0.14
Dec 22 00:19 : output: opened plugin=alsa name="HDMI" audio_format=96000:32:2
Dec 22 00:19 : output: converting from 705600:dsd:2
Dec 22 00:19 : client: [0] process command "status"
Dec 22 00:19 : client: [0] command returned 0
Dec 22 00:19 : client: [0] process command "playlistinfo "-1""
Dec 22 00:19 : client: [0] command returned 0
Dec 22 00:19 : client: [0] process command "currentsong"
Dec 22 00:19 : client: [0] command returned 0
Dec 22 00:19 : alsa_output: Underrun on ALSA device "hw:0,3"
Dec 22 00:19 : alsa_output: Underrun on ALSA device "hw:0,3"

96000:16:*

Dec 22 00:20 : playlist: play 0:"_test/2L - test/2L-050_stereo-DSD128_01.dff"
Dec 22 00:20 : client: [0] command returned 0
Dec 22 00:20 : decoder_thread: probing plugin dsdiff
Dec 22 00:20 : decoder: audio_format=705600:dsd:2, seekable=false
Dec 22 00:20 : alsa_output: opened hw:0,3 type=HW
Dec 22 00:20 : alsa_output: format=S16_LE (Signed 16 bit Little Endian)
Dec 22 00:20 : alsa_output: buffer: size=64..16384 time=666..170667
Dec 22 00:20 : alsa_output: period: size=32..8192 time=333..85334
Dec 22 00:20 : alsa_output: default period_time = buffer_time/4 = 170666/4 = 42666
Dec 22 00:20 : alsa_output: buffer_size=16384 period_size=4096
Dec 22 00:20 : libsamplerate: setting samplerate conversion ratio to 0.14
Dec 22 00:20 : output: opened plugin=alsa name="HDMI" audio_format=96000:16:2
Dec 22 00:20 : output: converting from 705600:dsd:2
Dec 22 00:20 : client: [0] process command "status"
Dec 22 00:20 : client: [0] command returned 0
Dec 22 00:20 : client: [0] process command "playlistinfo "-1""
Dec 22 00:20 : client: [0] command returned 0
Dec 22 00:20 : client: [0] process command "currentsong"
Dec 22 00:20 : client: [0] command returned 0
Dec 22 00:20 : alsa_output: Underrun on ALSA device "hw:0,3"

~0008177

conta (reporter)

EDIT:
Sorry, i put in the lines including "audio_output_..." in the audio-output section -> MPD doesn't see the settings.
I corected that and edited the verbose-logs in the last note.

In short words: the settings with 24bit does not give out sound. With 16bit it is possible to hear something. With 44100Hz there is less stuttering than with 96000Hz.
Hope that helps you!

~0008178

cirrus (administrator)

This is a top-level setting. Adding it to an audio_output setting has on effect, other than the warning about an unknown option in the log file. Please retry.

~0008179

conta (reporter)

OK, it's allways getting better - now only the first line
audio_output_format "*:32:*"
does not bring any sound. The others bring sound, but stuttering. The line with 16bit brings the least stuttering, sounds nearly ok. Here are the logs:

*:32:*

Dec 22 11:11 : playlist: play 0:"_test/2L - test/2L-050_stereo-DSD128_01.dff"
Dec 22 11:11 : decoder_thread: probing plugin dsdiff
Dec 22 11:11 : decoder: audio_format=705600:dsd:2, seekable=false
Dec 22 11:11 : decoder: converting to 705600:32:2
Dec 22 11:11 : client: [0] command returned 0
Dec 22 11:11 : alsa_output: opened hw:0,3 type=HW
Dec 22 11:11 : alsa_output: format=S32_LE (Signed 32 bit Little Endian)
Dec 22 11:11 : alsa_output: buffer: size=32..8192 time=166..42667
Dec 22 11:11 : alsa_output: period: size=16..4096 time=83..21334
Dec 22 11:11 : alsa_output: default period_time = buffer_time/4 = 42666/4 = 10666
Dec 22 11:11 : alsa_output: buffer_size=8192 period_size=2048
Dec 22 11:11 : libsamplerate: setting samplerate conversion ratio to 0.27
Dec 22 11:11 : output: opened plugin=alsa name="HDMI" audio_format=192000:32:2
Dec 22 11:11 : output: converting from 705600:32:2
Dec 22 11:11 : client: [0] process command "status"
Dec 22 11:11 : client: [0] command returned 0
Dec 22 11:11 : client: [0] process command "playlistinfo "-1""
Dec 22 11:11 : client: [0] command returned 0
Dec 22 11:11 : client: [0] process command "currentsong"
Dec 22 11:11 : client: [0] command returned 0
Dec 22 11:11 : alsa_output: Underrun on ALSA device "hw:0,3"
Dec 22 11:11 : alsa_output: Underrun on ALSA device "hw:0,3"

96000:32:*

Dec 22 11:12 : playlist: play 0:"_test/2L - test/2L-050_stereo-DSD128_01.dff"
Dec 22 11:12 : client: [0] command returned 0
Dec 22 11:12 : decoder_thread: probing plugin dsdiff
Dec 22 11:12 : decoder: audio_format=705600:dsd:2, seekable=false
Dec 22 11:12 : decoder: converting to 96000:32:2
Dec 22 11:12 : libsamplerate: setting samplerate conversion ratio to 0.14
Dec 22 11:12 : client: [0] process command "status"
Dec 22 11:12 : client: [0] command returned 0
Dec 22 11:12 : client: [0] process command "playlistinfo "-1""
Dec 22 11:12 : client: [0] command returned 0
Dec 22 11:12 : client: [0] process command "currentsong"
Dec 22 11:12 : client: [0] command returned 0
Dec 22 11:12 : client: [0] process command "status"
Dec 22 11:12 : client: [0] command returned 0
Dec 22 11:12 : client: [0] process command "playlistinfo "-1""
Dec 22 11:12 : client: [0] command returned 0
Dec 22 11:12 : client: [0] process command "currentsong"
Dec 22 11:12 : client: [0] command returned 0
Dec 22 11:12 : alsa_output: opened hw:0,3 type=HW
Dec 22 11:12 : alsa_output: format=S32_LE (Signed 32 bit Little Endian)
Dec 22 11:12 : alsa_output: buffer: size=32..8192 time=333..85334
Dec 22 11:12 : alsa_output: period: size=16..4096 time=166..42667
Dec 22 11:12 : alsa_output: default period_time = buffer_time/4 = 85333/4 = 21333
Dec 22 11:12 : alsa_output: buffer_size=8192 period_size=2048
Dec 22 11:12 : output: opened plugin=alsa name="HDMI" audio_format=96000:32:2
Dec 22 11:12 : client: [0] process command "status"
Dec 22 11:12 : client: [0] command returned 0
Dec 22 11:12 : client: [0] process command "playlistinfo "-1""
Dec 22 11:12 : client: [0] command returned 0
Dec 22 11:12 : client: [0] process command "currentsong"
Dec 22 11:12 : client: [0] command returned 0

96000:16:*

Dec 22 11:13 : playlist: play 0:"_test/2L - test/2L-050_stereo-DSD128_01.dff"
Dec 22 11:13 : client: [0] command returned 0
Dec 22 11:13 : decoder_thread: probing plugin dsdiff
Dec 22 11:13 : decoder: audio_format=705600:dsd:2, seekable=false
Dec 22 11:13 : decoder: converting to 96000:16:2
Dec 22 11:13 : libsamplerate: setting samplerate conversion ratio to 0.14
Dec 22 11:13 : client: [0] process command "status"
Dec 22 11:13 : client: [0] command returned 0
Dec 22 11:13 : client: [0] process command "playlistinfo "-1""
Dec 22 11:13 : client: [0] command returned 0
Dec 22 11:13 : client: [0] process command "currentsong"
Dec 22 11:13 : client: [0] command returned 0
Dec 22 11:13 : client: [0] process command "status"
Dec 22 11:13 : client: [0] command returned 0
Dec 22 11:13 : client: [0] process command "playlistinfo "-1""
Dec 22 11:13 : client: [0] command returned 0
Dec 22 11:13 : client: [0] process command "currentsong"
Dec 22 11:13 : client: [0] command returned 0
Dec 22 11:13 : client: [0] process command "status"
Dec 22 11:13 : client: [0] command returned 0
Dec 22 11:13 : client: [0] process command "playlistinfo "-1""
Dec 22 11:13 : client: [0] command returned 0
Dec 22 11:13 : client: [0] process command "currentsong"
Dec 22 11:13 : client: [0] command returned 0
Dec 22 11:13 : alsa_output: opened hw:0,3 type=HW
Dec 22 11:13 : alsa_output: format=S16_LE (Signed 16 bit Little Endian)
Dec 22 11:13 : alsa_output: buffer: size=64..16384 time=666..170667
Dec 22 11:13 : alsa_output: period: size=32..8192 time=333..85334
Dec 22 11:13 : alsa_output: default period_time = buffer_time/4 = 170666/4 = 42666
Dec 22 11:13 : alsa_output: buffer_size=16384 period_size=4096
Dec 22 11:13 : output: opened plugin=alsa name="HDMI" audio_format=96000:16:2
Dec 22 11:13 : client: [0] process command "status"
Dec 22 11:13 : client: [0] command returned 0
Dec 22 11:13 : client: [0] process command "playlistinfo "-1""
Dec 22 11:13 : client: [0] command returned 0
Dec 22 11:13 : client: [0] process command "currentsong"
Dec 22 11:13 : client: [0] command returned 0

PS:
Maybe important: In the logs of 96000:32:* and 96000:16:* are no alsa_underrun-messages. But still a little stuttering...

~0008180

cirrus (administrator)

This works better because it moves the PCM conversion from the output thread to the player thread, and thus reduces the output thread's internal latency.

16 bit works better because the period_time is twice as long for the same buffer_size.

However I have no idea why it still stutters even though the hardware driver does not report underruns.

~0008181

conta (reporter)

Last edited: 2013-12-22 17:27

View 2 revisions

Well, stuttering is maybe not the perfect word for the sound that is hearabel. It's more like hearing the music through a filter which adds a little static. A little like a bad audio-tape. Hard to describe. And, how i said, 96000:16 is better than 96000:32, but still not ok.
At least CPU-usage should not be the problem - all 3 lines cause a load of 26-31%. I would say far away from saturation.

EDIT: Is there maybe somebody, who can test the output of DSD128-files on a stronger PC?

~0008182

ranperry (reporter)

I have no issues playing DSD128 with the CPU barely making it past 3 percent. What do you use for the HDMI DAC?

~0008183

conta (reporter)

Are you playing with or without DoP?
HDMI-DAC here is a Yamaha-AVR.

~0008184

ranperry (reporter)

What is the model? Link?

~0008185

conta (reporter)

Yamaha AV-Receiver RX-V2700 - its not the worst. :-)
Did you test the DSD-output also as standard-PCM? Does it work out?

~0008203

ranperry (reporter)

It works for me without a problem although the process is not very CPU friendly. If you are trying to send 4/5/5.1 channels into your receiver, it may be just to much for your CPU.

~0008204

conta (reporter)

Well, when there are no problems on faster PC's outputting DSD128, the problem is solved, i would say?!
It seems, that a CPU-usage of only 25-30% can also cause troubles in some ways.
And one is for sure - my next music-PC will be no Atom... :-)
Thanks for the help!

~0008205

cirrus (administrator)

No, actually, my idea of MPD is that it works without stuttering up to 99% CPU usage.

~0008206

conta (reporter)

That sounds like a promise for the next year - hope you can manage it! would be perfect!
I wish everybody here a merry christmas!!!

~0008208

msmucr (reporter)

Last edited: 2013-12-24 14:59

View 2 revisions

Sorry for joining party late.. :-)
Your reading with top utility over 100% aren't crazy. This is actually how it interprets CPU usage numbers within multicore system. Each processing core usage represents 100%. So for instance if your Atom has two physical cores and enabled Intel HyperThreading, reading could be up to 400% for multithreaded process, which can utilize it. That is, why i asked for use of standard top utility, which is present on almost any Linux distribution. Other utilites could interpret usage differently with 100% as maximal sum for all cores, so its usage of 25% translates to 100% in top, if used on four core system.
MPD itself has several internal threads, like Cirrus mentioned, Decoder, Player, Output.. Operating system schedules that across your available cores, if any of this threads CPU utilization hits 100% (so one whole core), it starts to stutter.

And to resolution for this. Main hog with DSD playback is sample rate conversion as you found. Currently MPD has three available "engines" for it and some relevant settings in config file.
There is internal converter, which is very fast, bad sounding and don't work for DSD playback.
Then there is libsamplerate library, which is, what you is in mpd. Libsamplerate have several quality settings. All listed there:
http://www.musicpd.org/doc/user/ch03s09.html
Lower quality settings have also much lower processing requirements, so you could try that in your Atom setup. Default is - 2, and you could try - 4 (Linear Interpolator), that should make DSD128 playable, but you'll get quite significant drop in sound quality.
Third "engine" is library soxr, which offers good quality and low CPU usage, because is uses SIMD instructions of CPU. At my Celeron 847 during DSD128 playback it lowers CPU usage from 95% (libsamplerate fastest SINC) to merely 20%, while offering better quality.
As soxr option is quite fresh thing in mpd 19~git, it is usually not included in binary packages for Linux distributions. You can ask creator of your binary package for Ubuntu about that.
Second thing is, that i found, it preforms better, when converting DSD to sample rates with whole number ratio to original (eg. 44,1 88,2 176,4kHz Fs). So regarding that, i would create another output section in config file, named it with different name and added format 176400:32:* to it. And switch to before DSD playback. I believe, if you could manage that, it will help you with DSD128 at Atom.

Merry Christmas to all!

~0009796

conta (reporter)

Well, this time it's on me to be sorry for being late... :-)
I want to thank you for the good and extensive explanation of the problem.
AND you are totally right!
I successfully compiled mpd with soxr and now it is possible to playback DSD128 and even multichannelDSD without distortions. I am happy! :-)
The setting for "quality" is "high" - with "very high" there are sometimes distortions with multichannel. But "high" is also very good.
In the mpd-manual an option is described, to make soxr use multithreading - this would be perfect for my 4-core-IntelAtom (yes, still the same...). But unfortunately it seems that the syntax of the manual is not up to date?!
I will open a new thread about that.
Do you maybe know the correct syntax for this setting?
And once again: a big thankyou for your help!

~0010313

cirrus (administrator)

b1c7649edb80285c113f4710dd4c19d8f7c1aef7
+Notes

-Issue History
Date Modified Username Field Change
2013-12-08 13:54 conta New Issue
2013-12-08 20:16 ranperry Note Added: 0008102
2013-12-08 23:16 conta Note Added: 0008103
2013-12-09 01:33 ranperry Note Added: 0008104
2013-12-09 11:08 conta Note Added: 0008106
2013-12-09 14:56 conta Note Edited: 0008106 View Revisions
2013-12-09 15:31 ranperry Note Added: 0008112
2013-12-09 15:55 conta Note Added: 0008113
2013-12-09 16:51 ranperry Note Added: 0008114
2013-12-11 00:03 conta Note Added: 0008119
2013-12-11 00:09 ranperry Note Added: 0008120
2013-12-11 11:10 conta Note Added: 0008122
2013-12-11 14:31 conta Note Edited: 0008122 View Revisions
2013-12-11 14:34 conta Note Edited: 0008122 View Revisions
2013-12-19 09:39 cirrus Note Added: 0008148
2013-12-19 11:27 conta Note Added: 0008152
2013-12-20 18:35 cirrus Note Added: 0008162
2013-12-20 19:20 conta Note Added: 0008163
2013-12-20 19:57 msmucr Note Added: 0008164
2013-12-20 19:58 msmucr Note Edited: 0008164 View Revisions
2013-12-20 21:11 cirrus Note Added: 0008165
2013-12-21 00:04 conta Note Added: 0008166
2013-12-21 02:52 msmucr Note Added: 0008167
2013-12-21 11:14 cirrus Note Added: 0008168
2013-12-21 12:55 conta Note Added: 0008170
2013-12-21 13:03 cirrus Note Added: 0008171
2013-12-21 13:46 cirrus Note Added: 0008172
2013-12-22 00:10 conta Note Added: 0008176
2013-12-22 00:30 conta Note Added: 0008177
2013-12-22 00:34 conta Note Edited: 0008176 View Revisions
2013-12-22 10:14 cirrus Note Added: 0008178
2013-12-22 11:31 conta Note Added: 0008179
2013-12-22 13:55 cirrus Note Added: 0008180
2013-12-22 17:02 conta Note Added: 0008181
2013-12-22 17:27 conta Note Edited: 0008181 View Revisions
2013-12-22 17:39 ranperry Note Added: 0008182
2013-12-22 17:52 conta Note Added: 0008183
2013-12-22 18:02 ranperry Note Added: 0008184
2013-12-22 18:37 conta Note Added: 0008185
2013-12-23 17:13 ranperry Note Added: 0008203
2013-12-23 17:50 conta Note Added: 0008204
2013-12-23 18:22 cirrus Note Added: 0008205
2013-12-23 20:23 conta Note Added: 0008206
2013-12-24 14:44 msmucr Note Added: 0008208
2013-12-24 14:59 msmucr Note Edited: 0008208 View Revisions
2013-12-29 13:55 cirrus Severity minor => feature
2013-12-29 13:55 cirrus Summary DSD128 and DSD-Multichannel not working => Reduce output thread latency for DSD128 on Atom CPU
2014-12-12 13:55 cirrus Relationship added duplicate of 0003081
2016-02-21 13:35 conta Note Added: 0009796
2017-02-10 15:04 cirrus Assigned To => cirrus
2017-02-10 15:04 cirrus Status new => resolved
2017-02-10 15:04 cirrus Resolution open => duplicate
2017-02-10 15:04 cirrus Fixed in Version => git
2017-02-10 15:04 cirrus Note Added: 0010313
+Issue History