Audiolinux Server configurations, Software, Hardware, and Listening Impressions

[hifi25nl]

With new menu version 108 there is a new option "MPD --> select DAC and play from memory"

 

If you want to play a file from RAM you have these options:

1) Copy the files to audiolinux USB stick if in ram mode

2) MPD with the commands reported below (now easier with the new menu option)
3) Squeezelite with some output parameters

 

HQPlayer (max 250 ms cache) and Roon (cache unknown)  have not this possibility and there is no way to implement it from outside. 

...At least another player is declaring that it can play from RAM, but it is really using MPD...

 

This can be done also manually, editing the file /home/audiolinux/.mpdconf
See MPD parameters here: https://linux.die.net/man/5/mpd.conf

 

audio_buffer_size <size in KiB>
This specifies the size of the audio buffer in kibibytes. The default is 2048, large enough for nearly 12 seconds of CD-quality audio.
buffer_before_play <0-100%>
This specifies how much of the audio buffer should be filled before playing a song. Try increasing this if you hear skipping when manually changing songs. The default is 10%, a little over 1 second of CD-quality audio with the default buffer size.

 

Possible configuration:
audio_buffer_size "100000"
buffer_before_play "100%"

[nbpf]

1 hour ago, hifi25nl said:

With new there is a new option "MPD --> select DAC and play from memory"

 

If you want to play a file from RAM you have these options:

1) Copy the files to audiolinux USB stick if in ram mode

2) MPD with the commands reported below (now easier with the new menu option)
3) Squeezelite with some output parameters

 

HQPlayer (max 250 ms cache) and Roon (cache unknown)  have not this possibility and there is no way to implement it from outside. 

...At least another player is declaring that it can play from RAM, but it is really using MPD...

 

This can be done also manually, editing the file /home/audiolinux/.mpdconf
See MPD parameters here: https://linux.die.net/man/5/mpd.conf

 

audio_buffer_size <size in KiB>
This specifies the size of the audio buffer in kibibytes. The default is 2048, large enough for nearly 12 seconds of CD-quality audio.
buffer_before_play <0-100%>
This specifies how much of the audio buffer should be filled before playing a song. Try increasing this if you hear skipping when manually changing songs. The default is 10%, a little over 1 second of CD-quality audio with the default buffer size.

 

Possible configuration:
audio_buffer_size "100000"
buffer_before_play "100%"

I do not understand: "menu version 108" of what? I have used MPD since years and played around with audio_buffer_size

and buffer_before_play many times with no perceivable effects on the sound quality of my systems. Is there anything new in MPD?

[Dutch]

23 minutes ago, nbpf said:

I do not understand: "menu version 108" of what? I have used MPD since years and played around with audio_buffer_size

and buffer_before_play many times with no perceivable effects on the sound quality of my systems. Is there anything new in MPD?

 

You’re in a AudioLinux thread, v108 is the menu version of AudioLinux

 

http://www.audio-linux.com/

[nbpf]

10 minutes ago, Dutch said:

 

You’re in a AudioLinux thread, v108 is the menu version of AudioLinux

 

http://www.audio-linux.com/

Thanks, thus the message is that if one wants MPD to replay from memory, one has to modify the default values of 

audio_buffer_size and of buffer_before_play, right? But isn't this always the case, no matter whether MPD runs under AL, Debian or another distribution? 

[Dutch]

3 minutes ago, nbpf said:

Thanks, thus the message is that if one wants MPD to replay from memory, one has to modify the default values of 

audio_buffer_size and of buffer_before_play, right? But isn't this always the case, no matter whether MPD runs under AL, Debian or another distribution? 

 

I suppose so, but he’s just making it easier for the not so tech savvy users running AL.

[nbpf]

Just now, Dutch said:

 

I suppose so, but he’s just making it easier for the not so tech savvy users running AL.

I understand, thanks! It would be interesting to check whether under AL these settings make any difference. According to the MPD developers they should not. Indeed, I have never managed to hear any differences when playing around with these values under Raspbian (in my system, to my ears, etc.). But perhaps they make a difference under AL?

[rickca]

7 hours ago, hifi25nl said:

Squeezelite with some output parameters

Can you please be specific about the appropriate output parameters for Squeezelite?  

[hifi25nl]

It is the b parameter 

-b <stream>:<output>    Specify internal Stream and Output buffer sizes in Kbytes

 

See all squeezelite options here:

http://manpages.ubuntu.com/manpages/trusty/man1/squeezelite.1.html

 

Example for /etc/squeezelite.conf

OPTIONS="-b your_value:your_value -o front:CARD=Audio,DEV=0"

[lpost]

I'm running a Ryzen 1700X on a ASRock X370 Pro Gaming board.  2x8GB DDR4, low CL ram.

 

I've under clocked the proc to 2.2Ghz in bios (minimum) and disabled SMT (AMD hyper threading), ram clocked at slowest speed 1866, boot Extreme2, no core isolation, prioritize HQPe in rtapp and I2S sound board IRQ in rtirq.  Governor running performance, turbo off.  

 

Core temps remain solid at 56C-58C depending on ambient.  

 

Governor set to max runs it 65C, just a bit more than I like longterm and I don't perceive any/enough gain to justify the risk.

 

This combination sounds exceedingly good to me.  Great material sounds great and bad material sounds bad.  Soundstage is deep and very wide, wraps around me from time to time and catches me off guard.  I love it!  Zero fatigue and I listen 6-8 hours every day.

[Johnseye]

20 hours ago, hifi25nl said:

With new menu version 108 there is a new option "MPD --> select DAC and play from memory"

 

If you want to play a file from RAM you have these options:

1) Copy the files to audiolinux USB stick if in ram mode

2) MPD with the commands reported below (now easier with the new menu option)
3) Squeezelite with some output parameters

 

HQPlayer (max 250 ms cache) and Roon (cache unknown)  have not this possibility and there is no way to implement it from outside. 

...At least another player is declaring that it can play from RAM, but it is really using MPD...

 

This can be done also manually, editing the file /home/audiolinux/.mpdconf
See MPD parameters here: https://linux.die.net/man/5/mpd.conf

 

audio_buffer_size <size in KiB>
This specifies the size of the audio buffer in kibibytes. The default is 2048, large enough for nearly 12 seconds of CD-quality audio.
buffer_before_play <0-100%>
This specifies how much of the audio buffer should be filled before playing a song. Try increasing this if you hear skipping when manually changing songs. The default is 10%, a little over 1 second of CD-quality audio with the default buffer size.

 

Possible configuration:
audio_buffer_size "100000"
buffer_before_play "100%"

 

To confirm, if I'm streaming from Roon with HQPlayer to an HQPlayer NAA, with both OS's running AL, the MPD will not have an impact because HQPlayer overrides it? 

[hifi25nl]

As with all audio services, if you enable one, the other must be disabled.

To be sure select first

         2 "STOP and disable all running audio services"
and after start the services you want. In the case of Roon + HQPlayer you can enable both.

[Johnseye]

27 minutes ago, hifi25nl said:

As with all audio services, if you enable one, the other must be disabled.

To be sure select first

         2 "STOP and disable all running audio services"
and after start the services you want. In the case of Roon + HQPlayer you can enable both.

 

Right, so for Roon + HQPlayer you're saying using MPD has no relevance because they won't cache the entire song into RAM, even if AL is RAM loaded?  Or is that incorrect?

[hifi25nl]

Yes, Roon and HQPlayer are not caching the entire song to RAM, only a part of it

If you use MPD instead yes you can.

Obviously the configuration made on MPD has not relevance for other players.

 

I could make some tricks... change the name of MPD, create a new interface like Cantata, call it Audiolinux player, et voilà! I have a RAM player!

 

...Seriously I could arrange things so that some files in a specific folder of your music library (I guess many libraries are huge),  would automatically be loaded to RAM at boot, so that, if the folder is added in Roon or HQPlayer library configuration , they would play from RAM. Would this be convenient? I don't know. 

 

I think that users should ask that option to Roon and HQPlayer developers.

[Dutch]

Reading between the lines (or trying to) I think @hifi25nl is very politely saying Euphony Stylus is basically MPD.

[davide256]

35 minutes ago, hifi25nl said:

Yes, Roon and HQPlayer are not caching the entire song to RAM, only a part of it

If you use MPD instead yes you can.

Obviously the configuration made on MPD has not relevance for other players.

 

I could make some tricks... change the name of MPD, create a new interface like Cantata, call it Audiolinux player, et voilà! I have a RAM player!

 

...Seriously I could arrange things so that some files in a specific folder of your music library (I guess many libraries are huge),  would automatically be loaded to RAM at boot, so that, if the folder is added in Roon or HQPlayer library configuration , they would play from RAM. Would this be convenient? I don't know. 

 

I think that users should ask that option to Roon and HQPlayer developers.

So a play list cache option is the trick needed from Roon / HQPlayer; allow you to select a drive directory for playlist to be copied to/overwrite before beginning play? Would require that you could define ~8GB  RAM or Optane partition for this use. That would nicely eliminate SQ impacts from physical media choice for storage.

[Dutch]

RAM playback has been requested with Roon many times, thus far they’ve not ‘given in’. Since even that J company from Minnesota once did maybe they will one day as well.

 

https://community.roonlabs.com/t/does-roon-download-entire-track-into-ram-memory-playback-discussion/

[nbpf]

2 hours ago, davide256 said:

So a play list cache option is the trick needed from Roon / HQPlayer; allow you to select a drive directory for playlist to be copied to/overwrite before beginning play? Would require that you could define ~8GB  RAM or Optane partition for this use. That would nicely eliminate SQ impacts from physical media choice for storage.

But do you find that the physical media used for storage have a perceivable impact on the sound quality? You can set MPD to replay from memory in any distribution by tweaking the audio_buffer_size and the buffer_before_play values in /etc/mpd.conf. Or you can copy a few test files to the media that holds your OS and test whether this makes any difference. I have tried this many times in the past and I never could hear any differences in my system. As far as I remember, there  is (or there was) anyway an upper bound to the value of   audio_buffer_size that one can set, see https://forum.musicpd.org/viewtopic.php?f=9&t=3852&p=5604&hilit=nbpf#p5604. Perhaps this has changed in recent MPD versions? The default MPD values used to be 4096 and 10%, respectively,in contrast to what stated in the MPD documentation. The default Volumio values in Oct. 2018 were 8192 and 10%. I would be very surprised and, in fact, worried, if it would turn out that changing these values has a significant impact on the sound quality of MPD.

[ray-dude]

Alas, Roon optimizes for multi-room, multi-stream playback. That would be challenging with in memory caching, but doable. I hope they cave in this, but they’ve been adamant that it is incompatible with what they consider a core feature in their system. 

 

If you use Squeezelite as your LMS end point, Roon Core does respect caching the current and next track to the end point. With Squeezelite and a large input buffer, I did a fun experiment where I queued up 2 long tracks, hit play on Roon, disconnected my end point from Ethernet, and it happily played music from RAM for 20+ minutes. 

[davide256]

 

56 minutes ago, ray-dude said:

Alas, Roon optimizes for multi-room, multi-stream playback. That would be challenging with in memory caching, but doable. I hope they cave in this, but they’ve been adamant that it is incompatible with what they consider a core feature in their system. 

 

If you use Squeezelite as your LMS end point, Roon Core does respect caching the current and next track to the end point. With Squeezelite and a large input buffer, I did a fun experiment where I queued up 2 long tracks, hit play on Roon, disconnected my end point from Ethernet, and it happily played music from RAM for 20+ minutes. 

hmm, could you do this locally with AL, have Roonserver send to LMS as endpoint on same box? Eliminate local media access during track playback of an album?

[lpost]

On 3/29/2019 at 4:52 PM, lpost said:

I'm running a Ryzen 1700X on a ASRock X370 Pro Gaming board.  2x8GB DDR4, low CL ram.

 

I've under clocked the proc to 2.2Ghz in bios (minimum) and disabled SMT (AMD hyper threading)

 

 

 

Unfortunately, after a 3 multi hour listening sessions the system has become unstable.  Roon isn't happy and requires a full OS reboot.  Restarting Roon daemon only does not resolve.  Ah, well back to 'auto' CPU settings for now.

[ray-dude]

21 hours ago, davide256 said:

 

hmm, could you do this locally with AL, have Roonserver send to LMS as endpoint on same box? Eliminate local media access during track playback of an album?

 

I gave this a try this morning and it worked.  The caveat is to stop Roon server, start squeezelite, then start Roon Server (so Roon doesn't claim the USB device).  

 

I did not do any SQ comparison between Roon direct vs Roon to Squeezelite in a one box solution (I have a separate AL end point)

[lpost]

16 hours ago, lpost said:

 

Unfortunately, after a 3 multi hour listening sessions the system has become unstable.  Roon isn't happy and requires a full OS reboot.  Restarting Roon daemon only does not resolve.  Ah, well back to 'auto' CPU settings for now.

 

My issue were completely because of a wildly bloated Roon db.  7000 albums and it was 26GB!  Recreated from scratch, now it's 6GB.  System stable with all performance options enabled, ramroot, etc.

[LTG2010]

Audiolinux Tweaking
Here's a tweak to improve Roon and other audio players using alsa mixer, this degrades sound quality, Mpd and HQPlayer connect without alsa mixer.
To disable it:
Create a file in /etc directory:

asound.conf

the following parameters for the file:

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

Hopefully you should hear increased clarity, dynamics.....

It's been stated that audiolinux can sound thin / harsh/ lacking warmth etc...
Well it's transparency can reveal weaknesses in the hardware. Good thing is that it's ultra tweak-able and can be tuned to your processor /equipment.
Too harsh?
Try setting realtime priority to standard and boot to standard mode.
Still too harsh? then try tweaking the pstate_frequency parameters the directory is at: /etc/pstate-frequency.d
open: 00-auto.plan
change parameters:
from max to: balanced

open 02-balanced.plan
set:

PLAN_CPU_PSTATE_GOVERNOR=powersave (using the powersave algorithm the processor will not run as hot)
PLAN_CPU_MAX=100
PLAN_CPU_MIN=99
This will keep the processor at a constant full speed (you can play with these percentages as long as they are constant eg. 75/74)
Try turbo on and off whichever sounds best.

Don't forget to disable ramroot first or ramsave after editing files and reboot.

Thanks Piero for assistance.

 

[nbpf]

13 hours ago, LTG2010 said:

Audiolinux Tweaking
Here's a tweak to improve Roon and other audio players using alsa mixer, this degrades sound quality, Mpd and HQPlayer connect without alsa mixer.
To disable it:
Create a file in /etc directory:

asound.conf

the following parameters for the file:

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

Hopefully you should hear increased clarity, dynamics.....

It's been stated that audiolinux can sound thin / harsh/ lacking warmth etc...
Well it's transparency can reveal weaknesses in the hardware. Good thing is that it's ultra tweak-able and can be tuned to your processor /equipment.
Too harsh?
Try setting realtime priority to standard and boot to standard mode.
Still too harsh? then try tweaking the pstate_frequency parameters the directory is at: /etc/pstate-frequency.d
open: 00-auto.plan
change parameters:
from max to: balanced

open 02-balanced.plan
set:

PLAN_CPU_PSTATE_GOVERNOR=powersave (using the powersave algorithm the processor will not run as hot)
PLAN_CPU_MAX=100
PLAN_CPU_MIN=99
This will keep the processor at a constant full speed (you can play with these percentages as long as they are constant eg. 75/74)
Try turbo on and off whichever sounds best.

Don't forget to disable ramroot first or ramsave after editing files and reboot.

Thanks Piero for assistance.

 

 

What is the meaning of  

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

? Is it equivalent to setting mixer_type  to "none" in the alsa audio output section of /etc/mpd.conf? 

 

I am not sure that I see the point of using the powersave governor in a music server. Why not setting a fixed cpu frequency and let cpufrequtils out of the equation? One less package and less processes running in the background!  

[hifi25nl]

Yes and Yes...

 

but the asound.conf will apply to all applications, especially Roon