Dedicate CPU core for MPD

[hifinet]

I came across this post . Any thoughts specifically about the idea of dedicating a CPU core for MPD?

According to the author: By running the MPD process on a dedicated CPU core, it removes the last bit of harshness from the playback and makes the sound even more “analog”.

[Tim Curtis]

I came across this post . Any thoughts specifically about the idea of dedicating a CPU core for MPD?

According to the author: By running the MPD process on a dedicated CPU core, it removes the last bit of harshness from the playback and makes the sound even more “analog”.

Thats just the human mind convincing itself of such things. 

The fact is that MPD (and most other softwares) are specifically designed as multi-threaded applications that take advantage of multi-core CPU's. You never want to deliberately cram this type of application into a single CPU core :-0

Have a look below at the MPD + CamillaDSP process maps on a 4-core CPU and notice that separate threads of execution are created for specific parts of their main processes. The Linux kernel scheduler manages which physical CPU core a given thread is executed on. What this accomplishes is a high degree of execution parallelism allowing the application to attain max responsiveness, performance and efficiency.

- PID is the process id
- TID is the thread id
- CLS is the kernel scheduling class. TS (time sharing) is the default non-realtime class. FF is realtime FIFO.
- RTPRIO is the realtime priority (1 - 99) where 1 is highest priority.
- PSR is the processor core the thread last ran on

MPD

Code:

pi@moode9:~ $ ps H -q `pidof -s mpd` -o 'pid,tid,cls,rtprio,comm,pcpu psr'
   PID     TID CLS RTPRIO COMMAND         %CPU PSR
 43503   43503  TS      - mpd              0.9   1
 43503   43504  TS      - io               0.0   3
 43503   43505  FF     40 rtio             0.0   0
 43503   43719  TS      - player           0.0   1
 43503   43720  TS      - decoder:faad     0.8   2
 43503   43723  FF     40 output:ALSA Def  0.0   1
 43503   43782  TS      - pcm-io           0.0   0

 CamillaDSP

Code:

pi@moode9:~ $ ps H -q `pidof -s camilladsp` -o 'pid,tid,cls,rtprio,comm,pcpu psr'
  PID     TID CLS RTPRIO COMMAND         %CPU PSR
43724   43724  TS      - camilladsp       0.6   2
43724   43725  TS      - flexi_logger-as  0.0   2
43724   43726  TS      - flexi_logger-fl  0.0   1
43724   43727  TS      - camilladsp       0.0   0
43724   43728  TS      - camilladsp       0.0   2
43724   43729  TS      - camilladsp       0.0   2
43724   43731  TS      - camilladsp       0.1   1
43724   43732  TS      - AlsaPlayback     0.2   0
43724   43733  TS      - FileCapture      0.2   3

You can also run these commands inside a watch command and see the kernel scheduler in action as it seamlessly reassigns processor cores (in microseconds) as needed. The -n option is the interval in secs that tells watch how often to run the command.

Code:

watch -n .1 "ps H -q `pidof -s mpd` -o 'pid,tid,cls,rtprio,comm,pcpu psr'"

Also keep in mind that there are a lot of other processes and threads in execution for example the web stack (PHP-FPM and NGINX), moode worker, monitors and watchdog daemons, networking, file management, renderers, etc etc.

[hifinet]

Thank you for the detailed explanation. That makes a lot of sense.

The MPD manual says: Note There is a rumor that real-time scheduling improves audio quality. That is not true. All it does is reduce the probability of skipping (audio buffer xruns) when the computer is under heavy load.

Is it correct that the MPD output buffer enables low latencies of the I2S data stream (without CamillaDSP or SoX)?

Is there a flag for MPD audio buffer xruns?

[Tim Curtis]

The MPD dev, Max Kellermann is absolutely correct regarding real-time scheduling having nothing to do with audio quality. MPD reports generic buffer underruns in its log file. CamillaDSP also reports things in the MPD log.

/var/log/mpd/log or moodeutl --mpdlog

Latency in an audio pipeline is generally only important when creating music because things like tracking or overdubbing have to be heard in real time or they simply won't work. When just listening to music especially given the speed and throughput of modern computers and networks, latency should not be an issue.

Are you have a specific issue like audio glitches?

[hifinet]

A rare dropout.

[swizzle]

There’s a thread called system optimizations here that talks about reserving two cores for mpd and other such witchery but whether you can tell a difference, who knows. I used to believe back in the day but the newer kernels are already low latency. I’m not sure if all that stuff still works but if you’re still curious make a backup and the only thing you have to lose is time.

FWIW I just did the cpu isolation thing as shown in that thread (though it needs to be modified a little) and while it doesn’t seem to hurt I also don’t notice any great revelation in sound compared to standard 8.3.9. YMMV of course.

Underclocking still works too, going way down to 800 MHz still works but all moode back-end functions will be slower of course. I don’t recommend this but it doesn’t hurt to try.

[hifinet]

Another thing I want to try is to use only one core of a 2W. Using maxcpus=1 in /boot/cmdline.txt . Unfortunately, it requires a reboot, and can't be changed back to four cores during operation. I think I hear less noise with a single core Zero W compared to a four core 2W. Just playing files without any additional processing functions (CamillaDSP or SoX) seems to require very little CPU power. It's library management and other Moode functions that need more CPU power. Also, if future 32 bit Moode versions won't be developed, the 64 bit 2W would still be viable for Moode updates.

[the_bertrum]

I always want to to know the "how" of such optimisations. By which I mean, what is the noise in the sound output that you hear, and how does that noise get added to the signal by the un-optimised system. In this case, how does multiple cores add the noise? I think if that hypothesis can be formulated, then a test can be devised to measure the effect and thus prove it.
Otherwise we rely on "it sounds better to me", which is fine but is different to "is a more accurate reproduction of the recording", so it all depends I suppose on your desire.

[hifinet]

What is the noise in the sound output that you hear?

Low level white noise. There are many sources of white noise. There is white noise in the audio track. There can be white noise generated from other components in the stereo system. There needs to be a comparison to a source with less white noise. You can compare the sound with the DAC powered by a SMPS compared to the PurePi ultracap supply or a battery supply. The SMPS powered DAC has more white noise. The background is "blacker" = less white noise with the ultracap or battery supply. The problem is that once you hear your system with less noise, it is very difficult to go back. What to listen for is the first step. For example, dbx has a "pumping noise" as the background noise is increased and decreased with the dynamic expansion process. It is actually difficult to hear unless you know what to listen for. Once you hear it, though, you can't unhear it. It becomes difficult to ignore.

How does the noise get added to the signal?

Not sure. I think it is mostly through the wiring (direct electrical connections). Galvanic isolation can apparently help (no personal experience with this yet). There seems to be very little from radiated EMI. This is based on a setup I had with RPi USB to SPDIF to I2S, which was very quiet. I could not hear the difference between the DAC positioned feet away from the RPI, compared to sitting directly above the RPi.

How does multiple cores add the noise?

Not sure. I assume that each core generates switching noise. More cores = more noise? Using the maxcpus setting would be very informative. At this point, I have only compared different RPis. Noise is lowest in the Zero W. 3B has more noise than a 2B. There could be noise from other sources in the RPi, such as the switching regulators, for example. Greg Stewart (see diyA posts and now at Ian Canada) used to modify the RPi 2s onboard switching regulators to linear regulators for lower noise. The original RPi 1 is known to have low noise, and it has linear regulators, and is also single core.

[Tim Curtis]

What is the noise in the sound output that you hear?

Low level white noise. There are many sources of white noise. There is white noise in the audio track. There can be white noise generated from other components in the stereo system. There needs to be a comparison to a source with less white noise. You can compare the sound with the DAC powered by a SMPS compared to the PurePi ultracap supply or a battery supply. The SMPS powered DAC has more white noise. The background is "blacker" = less white noise with the ultracap or battery supply. The problem is that once you hear your system with less noise, it is very difficult to go back. What to listen for is the first step. For example, dbx has a "pumping noise" as the background noise is increased and decreased with the dynamic expansion process. It is actually difficult to hear unless you know what to listen for. Once you hear it, though, you can't unhear it. It becomes difficult to ignore.

How does the noise get added to the signal?

Not sure. I think it is mostly through the wiring (direct electrical connections). Galvanic isolation can apparently help (no personal experience with this yet). There seems to be very little from radiated EMI. This is based on a setup I had with RPi USB to SPDIF to I2S, which was very quiet. I could not hear the difference between the DAC positioned feet away from the RPI, compared to sitting directly above the RPi.

How does multiple cores add the noise?

Not sure. I assume that each core generates switching noise. More cores = more noise? Using the maxcpus setting would be very informative. At this point, I have only compared different RPis. Noise is lowest in the Zero W. 3B has more noise than a 2B. There could be noise from other sources in the RPi, such as the switching regulators, for example. Greg Stewart (see diyA posts and now at Ian Canada) used to modify the RPi 2s onboard switching regulators to linear regulators for lower noise. The original RPi 1 is known to have low noise, and it has linear regulators, and is also single core.

If audible noise is present in Raspberry Pi I2S interface then it should be easily measurable by an appropriate signal analyzer, and the noise source should be able to be traced.

Has anyone done an analysis and published the results for review?