lmitche Posted December 20, 2019 Author Share Posted December 20, 2019 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
hifi25nl Posted December 20, 2019 Share Posted December 20, 2019 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
lmitche Posted December 23, 2019 Author Share Posted December 23, 2019 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
ajm Posted December 23, 2019 Share Posted December 23, 2019 @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 Link to comment
lmitche Posted December 23, 2019 Author Share Posted December 23, 2019 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
hifi25nl Posted December 27, 2019 Share Posted December 27, 2019 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 elan120 1 AudioLinux --> https://www.audio-linux.com developer of AudioLinux realtime OS Link to comment
Boomboy Posted December 28, 2019 Share Posted December 28, 2019 do I need to be on version 2.1 for this ? I'm only on version 2.0 atm .. thnx Link to comment
luisma Posted December 30, 2019 Share Posted December 30, 2019 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
hifi25nl Posted December 30, 2019 Share Posted December 30, 2019 Upgrading from kernel 4.19.x to 5.4.x needs a full system update. Be advised that updating the system could not be easy (less problematic in headless version), so backup your system if possible. AudioLinux --> https://www.audio-linux.com developer of AudioLinux realtime OS Link to comment
luisma Posted December 30, 2019 Share Posted December 30, 2019 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
hifi25nl Posted December 30, 2019 Share Posted December 30, 2019 I have kernel 5.2.21.rt13 from 13 November that I can eventually upload. AudioLinux --> https://www.audio-linux.com developer of AudioLinux realtime OS Link to comment
hifi25nl Posted December 30, 2019 Share Posted December 30, 2019 The last before 5.4.x series was 5.2.x There is not a realtime kernel release for all kernels: https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/ AudioLinux --> https://www.audio-linux.com developer of AudioLinux realtime OS Link to comment
Miska Posted December 31, 2019 Share Posted December 31, 2019 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
adamthebrave Posted January 2, 2020 Share Posted January 2, 2020 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
hifi25nl Posted January 2, 2020 Share Posted January 2, 2020 "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) Oscarhuge 1 AudioLinux --> https://www.audio-linux.com developer of AudioLinux realtime OS Link to comment
bodiebill Posted January 3, 2020 Share Posted January 3, 2020 I have a two PC setup with AL + HQPe on a server and AL + NAA on an endpoint. Whatever the order in which I power up the PC's, I always have to stop all audio services on the server and start HQPe before my control point recognizes HQPe. Is there a way to make them handshake automatically? audio system Link to comment
hifi25nl Posted January 3, 2020 Share Posted January 3, 2020 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
bodiebill Posted January 3, 2020 Share Posted January 3, 2020 Seems to work, thanks! audio system Link to comment
juliocat Posted January 3, 2020 Share Posted January 3, 2020 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
hifi25nl Posted January 3, 2020 Share Posted January 3, 2020 ...go to INSTALL/UPDATE menu? AudioLinux --> https://www.audio-linux.com developer of AudioLinux realtime OS Link to comment
Miska Posted January 6, 2020 Share Posted January 6, 2020 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
bodiebill Posted January 6, 2020 Share Posted January 6, 2020 In my case hqplayerd runs under AL headless (GUI-less) version. Not sure how I should make the service dependent on network interfaces being up. (So far Piero's 'hack' works fine.) audio system Link to comment
hifi25nl Posted January 6, 2020 Share Posted January 6, 2020 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
Miska Posted January 6, 2020 Share Posted January 6, 2020 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
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now