Digital Music Server

Cogito · **Joined:** July 17th, 2016, 6:24 am **Posts:** 1132

Continuing from the WTB cheap Roon endpoint http://dcaudiodiy.com/phpBB3/viewtopic.php?f=5&t=1956 thread.....

What I found so far:
All CPUs have more than on core (a core is a CPU inside a physical CPU). Typically, the CPU usage of a music server is in low single digits. That low CPU usage is not an indication of quality of playback since all systems have multiple Cores and the OS manages the multi-tasking of all the processes, assigning them CPU based on some algorithm. That works extremely well for data computing needs, but for real-time computing needs like audio playback, multi-tasking becomes a hindrance. For example, if the music player, mpd, process is moved from core to core, it creates a time lag as all the memory structures need to be assigned to the new core which takes time.

GentooPlayer, a Linux distribution specialized for audio playback is highly configurable (thanks Grover for the tip). One of the features of GentooPlayer (GP for short) allows for pinning processes to cores. In the default GP configuration, mpd was skipping every time a track is changed manually in the music streamer (audirvana). And the quality of the playback was not up the mark when compared to the other music Linux distro, AP-Linux I was using. After I pinned the processes to CPUs, skipping has vanished and the quality of the playback improved.

This taught us two facts:
1. Overall CPU usage of the music server is immaterial. To get good performance, the music player process should be pinned to a core.
2. GP algorithm uses 4 cores for four different task categories. This means, fanless pcs with 2 cores are not ideal candidates for music servers. We need a desktop version of i5 (which has 4 cores) or better for the task, which requires some kind of active cooling.

Today, I came across a resampler for mpd called "Secret Rabbit Code"
http://www.mega-nerd.com/SRC/

SRC aka libsamplerate is compiled into mpd. It made a huge difference in my system. The difference is like moving from SS gear to tube gear. The only drawback of libsamplerate is, it is a CPU hog. I set the resample rate to 192kHz/24bit and tried few different types of sources.

With standard 44.1Khz/16bit PCM sources, the music server core was about 24-30% busy. Still, the resampled output was far more pleasing to my ear and there is no skipping.
With 192kHz/24bit PCM sources, music server core was around 27-35% busy and the resampled output was far more pleasing to my ear and there is no skipping. This should work ok for quboz,
With DSD64 sources, music server core was around 40% busy and the resampled output was far more pleasing to my ear and there is no skipping.

However with DSD128 source (Solo by Fiona Joy), the music server core was 94% busy and skipping started and eventually audirvana froze up.

The CPU I am using is only about 2.1Mhz. With this CPU, I cannot play anything over DSD64. Clock speed of the core is the prime important factor for quality music server implementation, which means we have to venture into HT/Gaming PC area. We dont need more than 4 cores. AMD Ryzen CPUs can be overclocked to 4.7MHz. Check out the hardware at Microcenter. Quality PSUs produce a max of 18dB and liquid cooling system with fans about 24dB. It will be a mid-tower which I would tuck it behind the speaker. My DAC can play 786kHz/32bit sources, which has to wait until I upgrade the server.

For anyone who wants to try out the libsamplerate resampler, make the following changes in /etc/mpd.conf and bounce it. I doubt it will work with low-end CPUs like atoms and celerons.

Attachment:

mpd_libcamplerate.png [ 32.25 KiB | Viewed 25032 times ]

DaveR, I read on that libsamplerate plugin is available for foobar200, if you wanted to try.

Grover Gardner · **Joined:** June 4th, 2013, 2:39 pm **Posts:** 502

Cogito wrote:

Continuing from the WTB cheap Roon endpoint http://dcaudiodiy.com/phpBB3/viewtopic.php?f=5&t=1956 thread.....

What I found so far:
All CPUs have more than on core (a core is a CPU inside a physical CPU). Typically, the CPU usage of a music server is in low single digits. That low CPU usage is not an indication of quality of playback since all systems have multiple Cores and the OS manages the multi-tasking of all the processes, assigning them CPU based on some algorithm. That works extremely well for data computing needs, but for real-time computing needs like audio playback, multi-tasking becomes a hindrance. For example, if the music player, mpd, process is moved from core to core, it creates a time lag as all the memory structures need to be assigned to the new core which takes time.

GentooPlayer, a Linux distribution specialized for audio playback is highly configurable (thanks Grover for the tip). One of the features of GentooPlayer (GP for short) allows for pinning processes to cores. In the default GP configuration, mpd was skipping every time a track is changed manually in the music streamer (audirvana). And the quality of the playback was not up the mark when compared to the other music Linux distro, AP-Linux I was using. After I pinned the processes to CPUs, skipping has vanished and the quality of the playback improved.

This taught us two facts:
1. Overall CPU usage of the music server is immaterial. To get good performance, the music player process should be pinned to a core.
2. GP algorithm uses 4 cores for four different task categories. This means, fanless pcs with 2 cores are not ideal candidates for music servers. We need a desktop version of i5 (which has 4 cores) or better for the task, which requires some kind of active cooling.

Today, I came across a resampler for mpd called "Secret Rabbit Code"
http://www.mega-nerd.com/SRC/

SRC aka libsamplerate is compiled into mpd. It made a huge difference in my system. The difference is like moving from SS gear to tube gear. The only drawback of libsamplerate is, it is a CPU hog. I set the resample rate to 192kHz/24bit and tried few different types of sources.

With standard 44.1Khz/16bit PCM sources, the music server core was about 24-30% busy. Still, the resampled output was far more pleasing to my ear and there is no skipping.
With 192kHz/24bit PCM sources, music server core was around 27-35% busy and the resampled output was far more pleasing to my ear and there is no skipping. This should work ok for quboz,
With DSD64 sources, music server core was around 40% busy and the resampled output was far more pleasing to my ear and there is no skipping.

However with DSD128 source (Solo by Fiona Joy), the music server core was 94% busy and skipping started and eventually audirvana froze up.

The CPU I am using is only about 2.1Mhz. With this CPU, I cannot play anything over DSD64. Clock speed of the core is the prime important factor for quality music server implementation, which means we have to venture into HT/Gaming PC area. We dont need more than 4 cores. AMD Ryzen CPUs can be overclocked to 4.7MHz. Check out the hardware at Microcenter. Quality PSUs produce a max of 18dB and liquid cooling system with fans about 24dB. It will be a mid-tower which I would tuck it behind the speaker. My DAC can play 786kHz/32bit sources, which has to wait until I upgrade the server.

For anyone who wants to try out the libsamplerate resampler, make the following changes in /etc/mpd.conf and bounce it. I doubt it will work with low-end CPUs like atoms and celerons.

Attachment:

mpd_libsamplerate.png

DaveR, I read on that libsamplerate plugin is available for foobar200, if you wanted to try.

Thank you, Shahsi! Not sure I can implement this but it's very interesting.

Roscoe Primrose · **Joined:** February 28th, 2013, 10:38 am **Posts:** 1712

Cogito wrote:

2. GP algorithm uses 4 cores for four different task categories. This means, fanless pcs with 2 cores are not ideal candidates for music servers. We need a desktop version of i5 (which has 4 cores) or better for the task, which requires some kind of active cooling.

There are plenty of 4 core fanless PCs out there...

Roscoe

HAL · **Joined:** January 13th, 2016, 9:14 pm **Posts:** 894

You might investigate quad core Intel Atom CPU's. They are SOC styles and have an LPE audio engine on chip that are direct I2S Bus to the USB ports.

The CPU offloads audio processing to the LPE, not CPU needed at that point and most players are memory players with Windows 10 that has built in drivers for the LPE.

A few of them out there and power requirements are below 10 watts and fanless. This is not new tech. Came out in 2015.

DaveR · **Joined:** February 19th, 2017, 9:43 am **Posts:** 535

Thanks Shashi, I'll check the re-sampler out.

I know my opinion flies in the face of the majority on this board, but an old I3, 5 or 7 PC with quiet fans can do anything you're asking for it to do. In fact, you could likely get away with an old Core 2 processor, but the I's can be had for so little now why not go for one of them? I have three boxes with fans in them in my listening room and you can't hear any fan noise.

Cogito · **Joined:** July 17th, 2016, 6:24 am **Posts:** 1132

DaveR wrote:

Thanks Shashi, I'll check the re-sampler out.

I know my opinion flies in the face of the majority on this board, but an old I3, 5 or 7 PC with quiet fans can do anything you're asking for it to do. In fact, you could likely get away with an old Core 2 processor, but the I's can be had for so little now why not go for one of them? I have three boxes with fans in them in my listening room and you can't hear any fan noise.

I am using i5 CPU now and it is not able to keep up with resampling DSD128. CPU clock speed is too slow for the task. That is why I am researching Ryzen overclocking. In addition to clock speeds of over 4MHz, Ryzen seems to be handling threads better than Intel CPUs. Reading that Ryzen is used for video rendering work due to its superior threading, which is exactly what is needed for running resembler.

Cogito · **Joined:** July 17th, 2016, 6:24 am **Posts:** 1132

Here is a review of Libsamplerate:

https://iandw.net/2014/06/29/secret-rab ... one-right/

Quote:

Hearing is subjective but as there are unlikely to be many who enjoy the sound of a road drill, I can point to some general improvements which hopefully others will be able to confirm. This moves digital audio back towards the sound of good vinyl, while remaining practical (aside – good vinyl can still be significantly better, but that is heavily dependent on the pressing and replay).

The main improvements I hear are:

A reduction in harshness; the better the resampling algorithm, the less harsh the music. This is a big deal for me as I was seriously considering changing my amplifier as CD was becoming too painful. Even the lowest quality algorithm is very good.

Openness and clarity in the high end. As expected from the theory, high frequencies benefit most. Cymbals now sound like cymbals rather than splashes of aggression. Drums have significant HF content and are an obviously improved area. Brass instruments can now sing smoothly, orchestral music can shine.

General improvements in tone and therefore naturalness in music reproduction. Almost all instruments have high frequency components to their sound, even when not playing high pitched notes (Fourier analysis again) , just look at a spectrum analyser such as a graphic equaliser to see that there are high frequencies everywhere. Some instruments come out particularly badly in digital and this helps.

I have been trying this out since yesterday and I think it is a must for Jazz. Haven’t tried other Genres yet.

David McGown · **Joined:** February 28th, 2013, 1:19 pm **Posts:** 957

Just an aside, the computation needs are dependent on if or where you do the "resampling". I would agree that a more powerful computer is needed to perform upsampling, in fact, I found that my i5 based NUC could not resample above DSD128 doing PCM->DSD conversion. Fortunately (though a rather expensive route), my Chord Hugo M Scalar upscales well beyond this on PCM, so my computer hardware needs are actually rather modest. Just handle bit-perfect original source through the computer to the USB output, and let the M Scalar do the rest.

I think a Ryzen should do nicely.

David

Cogito · **Joined:** July 17th, 2016, 6:24 am **Posts:** 1132

David McGown wrote:

Just an aside, the computation needs are dependent on if or where you do the "resampling". I would agree that a more powerful computer is needed to perform upsampling, in fact, I found that my i5 based NUC could not resample above DSD128 doing PCM->DSD conversion. Fortunately (though a rather expensive route), my Chord Hugo M Scalar upscales well beyond this on PCM, so my computer hardware needs are actually rather modest. Just handle bit-perfect original source through the computer to the USB output, and let the M Scalar do the rest.

I think a Ryzen should do nicely.

David

Ofcourse, if you have a dedicated scaler like that, there is no need for software resampling.

David McGown · **Joined:** February 28th, 2013, 1:19 pm **Posts:** 957

Shashi,

Although one can use (and should to experiment and find what works), there is a commercial upsampling player called HQPlayer that many people are using within Roon and standalone (w/ a server) The upsampling algorithms and filters are supposed to be very advanced and flexible, and there is one filter that uses a high number of tap (1M) like the M Scalar. You can download to try it out. It does take a very capable computer to process the files. I have NOT tried it, since I decided to go the route of the hardware M Scaler where the code is programmed in an FPGA that does nothing else. But from what I have read (not necessarily heard) is that many pushing the SOTA in renderers are using this software on a dedicated powerful rendering computer. Just putting that out there as something that might be worth the time to check out once you build your new renderer.

David

DCAudioDIY.com

Digital Music Server

Who is online