Audiolinux Server configurations, Software, Hardware, and Listening Impressions

[nbpf]

7 minutes ago, hifi25nl said:

Yes and Yes...

 

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

Thanks! ...

 

Good point!

[ronfint]

14 hours ago, LTG2010 said:

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

One immediate result of this is that all of the alsa mixer entries in Roon's settings>audio are now gone. I found them annoying; so that is already good. Second, this definitely improves clarity.  So thanks!

[LTG2010]

24 minutes ago, nbpf said:

Why not setting a fixed cpu frequency and let cpufrequtils out of the equation?

The same frequency using performance governor, resulted in a higher temperature than that in powersave. The resultant sound was less bright and harsh. I assumed that power to processor was being affected. It needs further investigation. A powersave option would be useful in audiolinux settings.

[lmitche]

18 minutes ago, hifi25nl said:

Yes and Yes...

 

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

Will you make this the default in future releases?

[hifi25nl]

Yes... 

[lmitche]

37 minutes ago, nbpf said:

Why not setting a fixed cpu frequency and let cpufrequtils out of the equation?

What is the best way to set frequency on a per core, or more accurately processor thread, basis?

[hifi25nl]

General wiki about frequency scaling:

https://wiki.archlinux.org/index.php/CPU_frequency_scaling

 

Do you mean difference frequencies for different cores?

This is not yet implemented in menu but is possible. 

After, f you want to run an application on a core that has a specific frequency, you can use "isolated cores"

[lmitche]

15 minutes ago, hifi25nl said:

General wiki about frequency scaling:

https://wiki.archlinux.org/index.php/CPU_frequency_scaling

 

Do you mean difference frequencies for different cores?

This is not yet implemented in menu but is possible. 

After, f you want to run an application on a core that has a specific frequency, you can use "isolated cores"

Yes different frequencies for different cores. Some cores scalable, some fixed.

 

The command line works for me.

[vortecjr]

On 3/29/2019 at 12:01 PM, 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%"

The issue with referring people to linux.die.net is that some of the information is out of date and the pages do not tell you which version of the application they corresponds to.

 

For example the buffer_before_play setting was removed in MPD 0.21. According to Max (who is the developer of MPD) users abused it to the point where MPD didn't work at all, for reasons nobody could ever explain to him. What does he recommend with respect to this setting...In older versions, don't mess with it. Anyway, depending on your version of MPD setting this parameter could do absolutely nothing. 

 

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

 

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

[vortecjr]

On 3/29/2019 at 2:02 PM, nbpf said:

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.

Exactly. That is because these settings do not affect sound quality.

 

According to Max don't change buffer/period settings. If you don't have xruns, then changing period/buffer doesn't do anything (other than increasing latency). I've never heard of a single case where changing the defaults has improved anything.

 

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.       

[vortecjr]

On 3/29/2019 at 7:10 PM, rickca said:

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

Some of the proposed configurations on this forum are nonsense. Translate this page to English via your browser and you will understand exactly what configuration is recommended.

http://marcoc1712.it/?p=458

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

[deanorthk]

Finally got my hardware ordered, I took the I7 6700K path, with a Z170 asrock fatality itx mb, and 16gb of RAM.

This will host audiolinux and roon coreI hope next month.

Just need to find a used chord polly and I'm good to go.

[LTG2010]

4 hours ago, vortecjr said:

For example the buffer_before_play setting was removed in MPD 0.21. According to Max (who is the developer of MPD) users abused it to the point where MPD didn't work at all, for reasons nobody could ever explain to him. 

Buffering before playback in theory reduces Hf distortion, from media such as ssd, according to manufacturers such as Innuos etc.

Jriver also don't believe there are audible benefits to buffering, but they still give their users the choice.

I don't think the developer of audiolinux ever claimed that a or b is better, but he quickly provides flexibility to users demands. People can try it for themselves. We tested changing buffer settings in squeezelite, there it makes a difference to sound quality, (we can hear it) If your equipment has enough ram at least you have the option to try it.

 

[vortecjr]

4 hours ago, nbpf said:

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. 

He is the leading expert on all things MPD. I have never found communicating with him to be an issue and I have been doing so for over a decade.

[vortecjr]

3 hours ago, nbpf said:

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. 

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     

[vortecjr]

4 hours ago, nbpf said:

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. 

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. 

[vortecjr]

3 hours ago, LTG2010 said:

Buffering before playback in theory reduces Hf distortion, from media such as ssd, according to manufacturers such as Innuos etc.

Jriver also don't believe there are audible benefits to buffering, but they still give their users the choice.

I don't think the developer of audiolinux ever claimed that a or b is better, but he quickly provides flexibility to users demands. People can try it for themselves. We tested changing buffer settings in squeezelite, there it makes a difference to sound quality, (we can hear it) If your equipment has enough ram at least you have the option to try it.

 

Then we should be able to measure it. If filling the buffer every few seconds impacted sound quality then the affect would be cyclic. 

[hifi25nl]

Just to clarify things: there is not a real default suggested configuration in audiolinux for MPD, Roon, HQPlayer etc

The audiolinux project propose some possibilities. It is up to the user decide if they are important for sound quality or not.

 

Since I have made some studio recordings, I remember here that audio total latency, very important for live performance, is not relevant for audio reproduction. What I test is not absolute latency but the variation of latency in time.

 

[vortecjr]

1 minute ago, hifi25nl said:

Just to clarify things: there is not a real default suggested configuration in audiolinux for MPD, Roon, HQPlayer etc

The audiolinux project propose some possibilities. It is up to the user decide if they are important for sound quality or not.

 

Since I have made some studio recordings, I remember here that audio total latency, very important for live performance, is not relevant for audio reproduction. What I test is not absolute latency but the variation of latency in time.

 

I appreciate the clarifications.

 

Understood. Agreed on the importance of low latency for live performances vs audio reproduction.

[LTG2010]

2 hours ago, vortecjr said:

Then we should be able to measure it. If filling the buffer every few seconds impacted sound quality then the affect would be cyclic. 

Pretty much agree that it should be measurable, but most of us here don't have the access to precision equipment, so second best is listening - if so many people reach the same conclusion then a consensus is formed. As most of us are not manufacturers we don't need to worry about justification of a product or software / method of use.

Latency and jitter co-exist and are related / affected. Ram has the lowest latency of current media and has the first and direct route to CPU.

One of the advantages of using Audiolinux (the reason I prefer its use) is the ability to load the entire operating system in RAM. Once this happens, the USB /SSD containing the OS is unmounted. Therefore the latency between OS USB/ SSD to CPU is not a factor.

In addition noise generated by that media, eg, high frequency noise from SSD, mechanical noise from hard discs is isolated.(noting that ram isn't noiseless)

Playback occurs directly from RAM to CPU. Following on from this principle we have storage media, ideally this also should be in RAM to keep the latency lowest. The problem with this is RAM is not persistent and inconvenient to use. Therefore there is an argument in buffering an entire album track in RAM and then providing lowest latency playback from that. At the same time isolating that data to a degree from the noise generated by the storage media.

I'm not trying to preach to you as you are an expert in isolation techniques, but if you are already in the 'playback from RAM camp' then it's best to get the most from it.

Incidently intel's new 'Optane persisten RAM' sounds pretty exciting from this perspective as both a storage and playback media.

https://www.intel.com/content/www/us/en/architecture-and-technology/optane-dc-persistent-memory.html

[RickyV]

11 minutes ago, LTG2010 said:

Pretty much agree that it should be measurable, but most of us here don't have the access to precision equipment, so second best is listening - if so many people reach the same conclusion then a consensus is formed. As most of us are not manufacturers we don't need to worry about justification of a product or software / method of use.

Latency and jitter co-exist and are related / affected. Ram has the lowest latency of current media and has the first and direct route to CPU.

One of the advantages of using Audiolinux (the reason I prefer its use) is the ability to load the entire operating system in RAM. Once this happens, the USB /SSD containing the OS is unmounted. Therefore the latency between OS USB/ SSD to CPU is not a factor.

In addition noise generated by that media, eg, high frequency noise from SSD, mechanical noise from hard discs is isolated.

Playback occurs directly from RAM to CPU. Following on from this principle we have storage media, ideally this also should be in RAM to keep the latency lowest. The problem with this is RAM is not persistent and inconvenient to use. Therefore there is an argument in buffering an entire album track in RAM and then providing lowest latency playback from that. At the same time isolating that data to a degree from the noise generated by the storage media.

I'm not trying to preach to you as you are an expert in isolation techniques, but if you are already in the 'playback from RAM camp' then it's best to get the most from it.

Incidently intel's new 'Optane persisten RAM' sounds pretty exciting from this perspective as both a storage and playback media.

https://www.intel.com/content/www/us/en/architecture-and-technology/optane-dc-persistent-memory.html

 

When reading this I had an idea. Isn't it possible to split/separate/ isolate the two ram banks and use one bank for the OS and the second bank for playback.

i am no expert 

[davide256]

Would like to try wifi on 7PJYH endpoint but the instructions aren't getting me there

https://www.audio-linux.com/html/wifi.html

 

when I try these I get

 

[audiolinux@audiolinux ~]$ ip addr show

....
3: wlo2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 20:16:b9:36:60:b4 brd ff:ff:ff:ff:ff:ff
[audiolinux@audiolinux ~]$ ip link set dev  wlo2 up
RTNETLINK answers: Operation not permitted
[audiolinux@audiolinux ~]$ touch /etc/wpa_supplicant/wpa_supplicant-wlo2.conf
touch: cannot touch '/etc/wpa_supplicant/wpa_supplicant-wlo2.conf': No such file or directory
[audiolinux@audiolinux ~]$

 

 

same using root

 

Suggestions?