Jump to content
IGNORED

Audiolinux Server configurations, Software, Hardware, and Listening Impressions


lmitche

Recommended Posts

4 hours ago, lmitche said:

Having just posted this on the Roonlabs support site, I think it makes sense to post here as well.

 

Today, after the Roon 1.7 build 511 Roonserver update and Roonbridge 1.0 build 171 installation RoonAppliance is core dumping on the server after initiating Qobuz playback at any resolution.

OS is AudioLinux. Server hardware is AMD Ryzen 7 2700 on Asus B450 motheboard.

Time to dump after playback is started varies by track and resolution. The dump could immediate or as long as 7 seconds depending on track resolution. The higher the resolution, the shorter the time to dump.

Playback from local files is normal with resolutions up to PCM384 and DSD256.

This behavior is the same when playback is started on multiple endpoint devices, Audiolinux/Roonbridge and Windows/Rooncore in control mode.

This problem is now fixed. It seems that the process pinning function in AL no longer works well with Roonserver. The app must have become resource starved in the latest release. Removing the pin fixed the problem.

 

Pareto Audio aka nuckleheadaudio

Link to comment

The problem in Roon is probably related to rtapp.timer enabled. This was fixed in the last menu versions and images.
In older installations you should disable rtapp.timer, update Audiolinux menu to last version and reboot:
systemctl disable rtapp.timer


This is kernel related, after 4.19.x version.

AudioLinux --> https://www.audio-linux.com

developer of AudioLinux realtime OS

Link to comment

A few weeks ago I posted a conjecture that Euphony, (built on Archlinux just like Audiolinux), defaults to the regular scheduler as opposed to the BFQ scheduler used by default in Audiolinux. The fact is I was wrong, Euphony definitely uses the BFQ scheduler as does Audiolinux.

 

So this eliminates the scheduler difference as the reason for any SQ between the two OS implementations.

 

Apologies for any confusion. 

 

Larry

 

 

Pareto Audio aka nuckleheadaudio

Link to comment
3 minutes ago, ajm said:

@lmitcheInteresting. Are you still finding the non-BFQ kernel produces preferable sound in AL2?

After reading your previous comment about this, I tried it and also preferred non-BFQ but unlike most people who have posted in this thread, I use HQ Player embedded without Roon.

 

Andrew

Yes, the "non-BFQ" scheduler is still in use here. There have been no comparison lately, but there should be time in the next week or so for some testing. After making the required Roon 1.7 adjustments, things sounds great here today. 

Pareto Audio aka nuckleheadaudio

Link to comment

Menu 212 with the new option REALTIME clock in EXPERT menu!

 

"This will set the Real Time Clock Frequency. Default in linux systems is 64.
In audiolinux is usually set to 3072. Suggested values are 1024, 2048. 3072 with a maximum of 8192.

If this is the first time you are using it, please select option 0) Update configuration. This option will reset custom and auto profiles and will add the new variable RTCLOCK"

 

Working on a new web control interface with touch screen compatibility and search function.

It should be available at the end of January

 

AudioLinux --> https://www.audio-linux.com

developer of AudioLinux realtime OS

Link to comment

Is anyone using AL + HQPe with NAA on a multihomed scenario? this is something with which I have recurring problems, don't know why, actually it should be related to multicast and the way HQPe + NAA works but there is something more here.

 

2 weeks ago I had an AL 2.1 server running ROON server + HPQe server, one wifi interface with default gateway to the internet, one wired interface with no default gateway separate network to an NAA. This NAA running AL 2.1 and only NAA service on it. This was working just fine. New kernel update 5.4 comes in (BFQ or non BFQ) multihomed stopped working, I went back to kernel 4.19 works, go to latest kernel again and multihomed stops working, go back to 4.19 all fine and dandy

 

Before AL I had Ubuntu and worked until one day I updated the kernel and did not worked anymore, I can't run a cable downstairs where the audio equipment is

 

Can anyone comment @hifi25nl and @Miska on what could it be creating the issue on the new kernel? I know I know HQPe doesn't officially support multi homed scenarios  neither I want anyone to try to find out the issue behind it, I am just asking for the eventful case someone knows anything about the new kernel which might be creating the issue

 

Thank you all

 

Luis

 

Link to comment

Yes I use headless and I wasn't using the 4.19, I progressively updated kernels on the 5.2 and 5.4 then found the problem, went back to 4.19 (with system previously fully updated) to make the multihomed worked

 

What is different on the 5.4 that the previous and 4.19 have?

 

Any way to downgrade to 4.2 or 4.3 or kernel from 2 weeks ago?

 

Link to comment
15 hours ago, luisma said:

Is anyone using AL + HQPe with NAA on a multihomed scenario? this is something with which I have recurring problems, don't know why, actually it should be related to multicast and the way HQPe + NAA works but there is something more here.

 

2 weeks ago I had an AL 2.1 server running ROON server + HPQe server, one wifi interface with default gateway to the internet, one wired interface with no default gateway separate network to an NAA. This NAA running AL 2.1 and only NAA service on it. This was working just fine. New kernel update 5.4 comes in (BFQ or non BFQ) multihomed stopped working, I went back to kernel 4.19 works, go to latest kernel again and multihomed stops working, go back to 4.19 all fine and dandy

 

Before AL I had Ubuntu and worked until one day I updated the kernel and did not worked anymore, I can't run a cable downstairs where the audio equipment is

 

Can anyone comment @hifi25nl and @Miska on what could it be creating the issue on the new kernel? I know I know HQPe doesn't officially support multi homed scenarios  neither I want anyone to try to find out the issue behind it, I am just asking for the eventful case someone knows anything about the new kernel which might be creating the issue

 

Thank you all

 

Luis

 

 

Best way to deal with multi-homed system is to run a bridged setup that turns the computer into a switch. But I would recommend to use a real switch instead of a software switch. If you need wireless to connect rooms/floors, you could use wireless bridges and a switch to transparently bridge two segments of the same network together.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
On 12/27/2019 at 5:31 PM, hifi25nl said:

Menu 212 with the new option REALTIME clock in EXPERT menu!

 

"This will set the Real Time Clock Frequency. Default in linux systems is 64.
In audiolinux is usually set to 3072. Suggested values are 1024, 2048. 3072 with a maximum of 8192.

If this is the first time you are using it, please select option 0) Update configuration. This option will reset custom and auto profiles and will add the new variable RTCLOCK"

 

Working on a new web control interface with touch screen compatibility and search function.

It should be available at the end of January

 

 

Can you exaplain for not experts what is the meaning of this?

Link to comment

"The command changes how accurately the HPET and timer can be accessed, the standard being 1/64th of a second. That's plenty fine for word processing, you probably want something more resolute for audiophile work - a few thousand Hz will do. Of course it also means if there are more HPET requests than there is frequency to handle them at the standard frequency, upping the frequency can resolve this (if it doesn't come at the expense of other resources)."

 

(quotation from a discussion in stereo.net.au)

AudioLinux --> https://www.audio-linux.com

developer of AudioLinux realtime OS

Link to comment

It could be a slow network discovery.

Because of this the hqplayer systemd service file /usr/lib/systemd/user/hqplayerd.service has the option ExecStartPre:

# ExecStartPre=/bin/sleep 30

You can edit it with File Editor Root in SYSTEM menu and remove #

ExecStartPre=/bin/sleep 30

You can also change the time to higher value, for example 60

-> Endpoint must be up before starting hqplayer on server.

 

 

AudioLinux --> https://www.audio-linux.com

developer of AudioLinux realtime OS

Link to comment

How can i install MPD on Audiolinux 2.1

 

Thanks

Hackintosh I7 16GB Ram, Roon, HQPlayer, Drobo 8 TB NAS, Raspberry Pi 3 NAA, Gustard X20 ES 9018 Xmos, Audio GD C39 Preamp, The First ONE DIY Amp, Monitor Audio GS20 Speakers, Monitor Audio RSW12 Subwoofer, PI Audio MagikBuss filter.

Link to comment

Above failure likely happens because all network interfaces are not properly up before hqplayerd is started. Adding sleep is a hack, not a proper fix. Correct fix is to make hqplayerd.service depend on all network interfaces being fully brought up. How this is done, depends on the particular OS, IOW, what kind of system is used to configure the network interfaces.

 

Another common problem is when OS has a GUI and typically in such cases network interface configuration is managed through the user session once logged in (using NetworkManager for example). In these cases, hqplayerd should not be started as a system service at all, but instead as a user session service (this also enables MPRIS control to work). This also relocates all configuration to be under each user's home folder instead of being system-wide. Above sleep hack may also make this situation work, if user logs in the session quick enough no to exhaust the sleep, but also in this case it is not a proper fix.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment

The sleep option is not there because of problems about network in the server. Network on the server is up and running, but hqplayer has not discovered yet the remote endpoint.

The alternative solutions are more complex, that is adding a system to check that the endpoint is up and accessible. Not sure if hqplayer will try to connect to endpoint repeatedly (and for how much time) until this is true.

AudioLinux --> https://www.audio-linux.com

developer of AudioLinux realtime OS

Link to comment
1 hour ago, hifi25nl said:

The sleep option is not there because of problems about network in the server. Network on the server is up and running, but hqplayer has not discovered yet the remote endpoint.

 

How does delaying starting of hqplayerd help hqplayerd to discover something since the discovery has not even started yet?

 

In addition, once started, HQPlayer runs a background loop looking for the NAA forever until it succeeds. And if it gets disconnected, the loop is started again.

 

1 hour ago, hifi25nl said:

The alternative solutions are more complex, that is adding a system to check that the endpoint is up and accessible. Not sure if hqplayer will try to connect to endpoint repeatedly (and for how much time) until this is true.

 

Yes it does...

 

 

But the original posting was talking also about control point, which refers to UPnP (or alternatively HQPlayer Client or HQPDcontrol app which are not technically called control points, but clients). In this case, discovery is made by the control point to find hqplayerd. Listening for discovery is started at the time hqplayerd started and it hooks to the network interfaces available at that moment.

 

 

One common problem for example is that network interface is "up", but DHCP client has not yet obtained leases from DHCP server for all the affected interfaces, so IP addresses of one or more interfaces are missing until the DHCP has fully configured all applicable interfaces. If the DHCP eventually fails on an interface, for one reason or the other, only at that point a link-local IP is configured for that interface.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...