Audiolinux Server configurations, Software, Hardware, and Listening Impressions

[nbpf]

Can AL for Raspberry Pi (3 B+) meanwhile run in RAM? Thanks, nbpf 

[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?

[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? 

[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?

[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.

[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!  

[nbpf]

7 minutes ago, hifi25nl said:

Yes and Yes...

 

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

Thanks! ...

 

Good point!

[nbpf]

2 hours ago, vortecjr said:

...

According to Max...nobody has ever improved anything by twiddling with any of these settings.

True, although it is probably fair to say that Max opinions on which MPD settings can have an impact on sound quality and which one cannot are most likely based on his knowledge, not on experience. I have also to say that I have found his attitude dogmatic to the point of making the communication with him impossible. 

[nbpf]

2 hours ago, vortecjr said:

Some here have been claiming that their low latency configurations are the key to their perceived sound quality gains. I guess they don't know that adding huge buffers adds...latency.       

You are talking about a very different kind of latency here: of course loading a full track into memory takes time and thus there is a perceivable delay between the time one selects a track for replay and the time replay actually starts. But this has absolutely nothing to do with latency as a measure of the time it takes for a running process to react to a system interrupt. This is the kind of latency that people running run-time kernels are trying to keep in check. In fact, what run-time kernels attempt at reducing is the maximal latency, sometimes at the expense of average latency. To the best of my knowledge the impact of different latency measures on sound quality is not well understood (let apart documented) and certainly worth being investigated. 

[nbpf]

2 hours ago, vortecjr said:

...

BTW Max is also thinking of removing the audio_buffer_size setting in future releases for the same reason.

...

This would be a major mistake because there are, indeed, combination of platform + transport for which the default values need to be slightly modified to prevent issues at the very beginning (less than one second) of replay. While Max is certainly very knowledgeable, his experience is necessarily limited. Thus, having a the possibility of altering these values is very welcomed. Also, notice that the default values of certain distributions (e.g., Volumio) slightly differ from the default MPD values. 

[nbpf]

6 hours ago, vortecjr said:

No and no it's not when people put in silly numbers because they don't understand the ramifications of it. BTW the ramifications are that the system becomes unstable, as has been reported here numerous time, and the developer gets numerous complaints. Volumio's settings will naturally differ because Volumio is different than MPD. You said the key word though...it differs "slightly". Notice its doesn't differ grossly from recommended values. BTW Max will certainly give MPD the smarts to decide the best value for these settings rather than rely on guess work from the user. This will make things more efficient where the player can decide what is best based on sample rate and bit rate and not on some fixed value in a configuration file. 

Volumio does use, among others, MPD ans sets 

 

audio_buffer_size               "8192"
buffer_before_play               "10%"

 

instead of the MPD defaults

 

audio_buffer_size               "4096"
buffer_before_play               "10%"

 

in /etc/mpd.conf. This is a minor change that can be very useful also under plain Raspbian for certain platforms. I am fully confident that Max will come up with meaningful MPD upgrades. On the other hand, the two settings and the potential implications of changing their default values by large amounts are well documented in the official MPD documentation. Thus, if users play around with them and run into troubles is their fault. Not a reason to impair the customizability of MPD, in my view.  

 

[nbpf]

7 hours ago, vortecjr said:

The point of a real time kernel is to process data as it comes in without buffer delays. Besides an asynchronous DAC will pull that data from the player as it sees fit and it doesn't care about how you fill the buffer. The DAC only cares that the buffer has the data it needs, when it needs it. The affects on sound quality are well documented and its called a "dropout". Dropouts resulting from xruns are bad for sound quality     

No, the point of a RT kernel is to establish a predictable upper bound on latency. It is just a different way of scheduling processes which has nothing to do with buffer delays.

[nbpf]

9 hours ago, vortecjr said:

It means your are redefining ALSA's default device with a slave device hw via the pcm interface.

Thanks!

[nbpf]

For what is worth, these https://www.24bit96.com/hifi-music-server/bitperfect-linux-with-mpd.html are the basic guidelines that I typically follow when setting up alsa and MPD in my minimal Debian systems. Perhaps there are more up to date guidelines, in which case, please share.