If you disagree with that best you disagree with your initial proposition too, audio engineer or not. Seems you’re going to follow your own ideas regardless so why ask anyone for input seeing as you know better.
One example on a DSD track that will not play more than a few seconds, is the excellent track Eric Bibb - Meeting at the building. According to Roon, I have it in a DSF DSD 128 2ch variant, and then the problem seems to be conversion from DSD128 to 705.6 kHz and then further conversion to 176.4kHz.
Roon plays for a few seconds, then things go awry, and soon after the “standard” Roon error message for such cases appear: “An audio file is loading slowly. This may indicate a performance or hardware problem”
I have confirmed that Audirvana (that I purchased a few days ago actually to test this problem!) plays the exact same track perfectly and at the low burner. On the DAC it says “176.4kHz”
I find it likely that Roon lacks compliance to this particular format, because another track from Opus3; Omnibus Wind ensemble - Music by Frank Zappa, plays perfectly, allthough with a “funny” cpu usage of approx 30% (application) and 13% (system) cpu usage. For this track, the (only) conversion is from DSD64 to PCM 352.8kHz. However, on the DAC, it still says 176.4kHz.
Audirvana plays this track seemingly with much more sophistaced algorithms, as the total cpu usage is well under 10%.
Note: I purchased these two cds first and foremost to test if my setup is DSD ready, so I don’t have more examples. Tracks can be purchased at opus 3 online store.
Yes, I found those articles interesting and I agree in the concept therein described, but this all depends on the quality of your gear. I will try to describe the setup. Hope it is helpful.
I no longer have Krell 250W Class A Mono blocks and Martin Logan Prodigy, but I do have Dali speakers which I listen to in the nearfield (<1meter) and the audio quality is thus OK. (It is helpful with SoundPimp, which beyond providing the fine masked details of the recording also provides a 150 degree soundstage which is closer to reality than the +60 you get with normal stereo.)
For this setup I put an SSD into a vintage Macbook Air (1.8Ghz), and being unaware of your guidelines, however implementing a general best practice, configured another Windows10 computer as Roon core. I thus had a setup with separate core and control.
This Mac was also stripped of all redundant OS X task, like search, etc, etc. A special script is available that strips down the computer to a minimum of tasks. It is thus a machine with almost no other activity than Roon and a few other mediaplayers, for example a radio that I wrote myself (I have not yet tried the Roon variant). It is thus a dedicated machine for audio-only streaming. This is the only task.
Hence, it acted similar to an audio-qualitative Roon Bridge with a USB connected DAC, or utilizing sometimes Airplay audio when I wanted to cast to other stereo systems and was less focused on audiophile quality.
HOWEVER, I had to abandon this strategy and put the core on this Mac, for the reason that the connection between the machines in the local network was unstable. This is an equation with several unknown, here a list of some of my problems, they all were giant time thieves:
(1) A Windows10 computer was unable to contact this Mac core until I deleted the Roon files on the computer and reinstalled Roon. It could then once again see the Mac core. This was a recent problem.
(2) the Mac core cannot always see my music library (on a wireless unix harddrive; Seagate), unless I babysit and manually browse my way to that drive via Roon settings. Only then would Roon reconnect to the predefined library paths defined. This appears to be a bug in Roon because it often happens also when problem (3) is not present, i.e. when OS X do see the unit fully!
(3) For oddball security reasons, the OS X will not always see units on the network that was there “yesterday” in this always on network, not until I babysit and manually browse a couple of times on the network. OS X then resync as well, so that Roon can subsequently do the same.
(4) There is, or at least it was, a significant delay in the network discovery features of OS X, not even close to resembling the speed of light. (minutes of waiting).
From all this, the Mac is now defined as core and this gives me a nice setup given that it is only used for Roon and radio (and Audirvana currently for testing).
I thought the error message stated elsewhere in this thread was related to WiFi trouble, so I moved the DSD and other high resolution media to the local SSD disk. (Audirvana shows me this was unnecessary, it can play DSD over WiFi as a breeze).
I can add additionally that I tend to explore known material already available through Tidal or my local music library. There should therefore be a limit as to how much work Roon needs to do in order to keep up with metainformation. I anticipate it is there for the local library?
It is in this setting that I would very much like – occasionally – to be able to tell Roon to calm down and only play what I ask it to play. If this user need is at cross purpose the general Roon philosophy, then please give me a secret shortcut key for it. It would be much better than the alternative suggested in the linked tutorials on good sound, which is to enter Roon setting and turn off this and that feature that I want back in an hour from now. Tedious.
Such a toggle would immediately enhance my user experience with Roon.
It is suggested here and in the knowledge base to add another Roon Bridge to cure the system of CPU trouble, but honestly speaking, this is highly unnecessary in my current hifi gear setup, as I said without the Krell monsters.
Rather, I hope to have Roon up and running on improved DSD algorithms and use the core directly via USB to DAC. I am happy with that.
Conclusion: I am going to use the Mac as core until further notice, i.e. until I feel safe to move the Roon Database back to the Windows 10 machine that lost the job mostly from force majeure reasons (the missing stability of the network).
REGARDING DSD: I am unable to find any settings resembling the alternatives you mention, i.e. DSD to PCM conversion as opposed to DSD over PCM. I would like to try the latter. How can I achieve that? (The underlying system is equal for Audirvana and Roon).
What is the exact model of the ‘vintage Macbook Air’ you are talking about? Since you speak of ‘putting in an SSD’, I’d guess this is a 2008 or 2009 model. These are about the worst Macs every manufactured, heavily compromised in almost every aspect (CPU throttling, networking, HDD/SDD speed) and woefully underpowered for running Roon Core. Also: running task killing scripts tends to go hand in hand with unpredictable/unwanted behaviour at OS level.
Correct that it is a 2009 model, and that it is lousy, but it works with most things that are not relying heavily on a compliant GPU. The outdated GPU is the main trouble with this machine. This is mostly a software problem, for example that Adobe Flash is non-backwards compliant. With compliant GPU software, this problem is also gone.
The SSD created a new machine out of it!
The GPU problems is why it is used for audio only. It works like a charm with normal use of Roon (core and control), using Tidal or CD quality. The DSD files not working is perhaps not related to the machine at all?
The trouble arrives with certain high resolution playback, but only with Roon, not with other players. So I am hoping to being able to setup Roon according to instructions given in this thread, but I don’t know yet how to do it.
My main question was actually something else; I would like a toggle to put of all the activities that I can also disable manually in the Roon settings. See my other outline. This is independant of machine used, except that a vintage would expose high cpu usage of this or that software, a usage that would often be not visible on a more modern machine. Testing software on old machine can be a good thing.
@Carl_Henrik_Janson – have you ruled out Brian’s theory?
You can check your DAC’s configuration in the Audio tab of Settings – if your DAC support it, your DSD Playback Strategy should be set to DSD Over PCM (DoP).
If that’s not it, let us know and @support will have a deeper look at this.
Thanks to all contributors on this thread and a happy new year!
In my ignorance without that much experience on DSD in particular, I saw only the general DSD setting under audio. Once I found the DAC specific DSD settings, I can now play whatever DSD format thanks to advice given. For the Eric Bibb track, the DAC now proudly anounces DSD 5.6, instead of PCM conversion to 176.4kHz.
Please cancel that remark about non-playable tracks and sorry for the inconvenience.
However, there seems to be an issue related to cpu usage. Testing Audirvana with both “DSD over PCM” 1.0 and 1.1, and with the application not visible so as to not provoke GUI handling on this vintage machine with an outdated GPU, the cpu usage is below 6%, and here Audirvana uses 1.5%, the rest being use of system resources.
If the GUI is shown fullscreen the cpu usages increases to +7%, i.e. not much of a difference.
Setting up Roon in the exact same way, the “stable state” cpu usage without visible GUI is +27%, including:
kernel task = 9%
RAATserver = 6%
If Roon GUI is shown the cpu usage increases to +36% as an approximate minimum value. +10% increase in resources is quite a lot just to show a moving peakbar, but this must be double checked on a more modern machine because the reason in my case could be that Roon utilizes more modern GPU features and thus this old GPU is provoked from lack of compliance to such features.
For comparision, and this is my normal case, playing a wav track (cd quality) over wifi, not showing gui, uses approx +15% cpu. IOW the cost of DSD is approx 10% added.
The basic mean cpu usage of Roon control + core on this machine seems to be approx 3%.
Anyway, as you see I am using a vintage MacBook Air upgraded with an SSD instead of a cubieboard or similar. It was done as an experiment. If I had top notch hifi gear, I would probably have considered installing a Roon bridge on it, but at the moment I use it as a roon core and this works very well. It is also used as one of the control machines.
The main reason for starting this thread was a feature request to enter minimalist mode on occasion. I hope it is filed as such.
Thanks for your help.
Added DSP features in 1.3 means Roon will be getting more processor intensive, not less, particularly when installed on under spec devices.
Rather than attempting to plug the everleaking dike of minimalisit processing in a general computer Roon have released Roon Bridge, which Isolates computing noise issues by allowing an inexpensive small footprint device to be interposed in the audio chain.
Minimalist mode seems to me to be an answer to a problem that already has a better solution. I can’t see that it is worth the opportunity cost of diverting development resources from other features, such as remote usage for cars or mobiles.
The concept with a Roon bridge is understood and saluted as such, but this is absolutely not mutually exclusive to a “less dramatic” minimalist mode implementation. They would be more like complementary. I must disagree and make reference to my “typical user” needs. A minimalist toggle feature is easily implemented and very practical, while the Roon Bridge is quite a dramatic change to my setting. I need a new device, a new software package, and time to make it work. Absolutely not a better solution for my user case. Thus, not going to happen.
[quote=“Carl_Henrik_Janson, post:17, topic:17624”]
A minimalist toggle feature is easily implemented and very practical
[/quote]By what understanding of Roon’s architecture and design do you arrive at this conclusion.
[quote=“Carl_Henrik_Janson, post:17, topic:17624”]
Thus, not going to happen.
[/quote]Ditto a minimalist toggle feature.
This is a rough interpretation of the Roon knowledge base which states how it is possible in settings to turn off this and that feature, for example background and on-demand audio analysis (etc).
So I can do this today already, but it is a bit tedious to enter settings and do several turn-offs. Then return some hours later to put them on again.
Hence I request a “minimalist toggle” that includes toggling of these and possibly other features.
You say it can’t be done easily?
OK.
I have a couple of comments to make on the Roon’s setting options you mentioned that may aid your understanding.
Background audio analysis only happens where new albums are added to Roon, typically:
- The first time a watched folder is setup and pointed at your library
- When new album files are added to an existing watched folder
Once the file has had its audio analysed it is not re-analysed unless:
- The file is changed
- The Roon Core is updated with a new audio analysis algorithm.(this will happen with v1.3)
On-demand audio analysis is triggered when the file is first played and that file has not previous been analysed i.e. it happens once.
So what I’m getting round to saying is that once audio analysis has been completed for all files, these flags make no difference to Roon CPU uses. With a small lib of circa 1500 albums background audio analysis should complete in a matter of a few hours.
If you have background audio analysis enabled and you not seeing the spinning circle (toward the top right of the Roon GUI) then is had completed.
Are there any other setting option that you have been frequently toggling, to reduce CPU usage?
Metadata Management
There is another background task that Roon performs, and that is checking for updated metadata (on the Roon servers) for your files. There are no user flags to switch this off. @Brian would be able to comment on how much CPU this function takes but my understanding is that it already well optimised.
Hope that helps.
1 Like
Hi again @Carl_Henrik_Janson,
For comparison this is what I observe running Roon 64bit on my Lenovo i7 8GB RAM PC running Windows 10 64 bit.
Background and on demand audio analysis enabled, however all files have been analysed (so this is moot).
Roon CPU usage.
Roon Minimised, Not Playing: Roon 0.0% CPU, RAAT 0.0%
Roon Maximised, Not Playing: Roon 0.1% CPU, RAAT 0.0%
Roon Minimised, Playing PCM FLAC 44/16: Roon 0.2% CPU, RAAT 0.1%
Roon Maximised, Playing PCM: FLAC 44/16: Roon 0.9% CPU, RAAT 0.1%
Roon Minimised, Playing PCM: WAV 44/16: Roon 0.2% CPU, RAAT 0.1%
Roon Maximised, Playing PCM: WAV 44/16: Roon 0.9% CPU, RAAT 0.1%
Roon Minimised, Playing PCM FLAC 192/24: Roon 0.9% CPU, RAAT 0.2%
Roon Maximised, Playing PCM: FLAC 192/24: Roon 1.5% CPU, RAAT 0.2%
Total CPU usage for the PC during these tests circa 5% to 6%.
Sorry, I don’t have an DSD to hand (I don’t have a DSD DAC), but will load some up and test transcoding to PCM a little later today.
Yes, this helps my understanding, and this is how I thought it worked until I read this
http://kb.roonlabs.com/Sound_Quality_in_One_Computer
the other day, where Roon recommend to turn off audio analysis, which allbeit is then not very important in the context of lowering CPU usages and enhancing sound quality.
The remaining question for me would be what and why Roon is using all that cpu just to play a wav of cd quality, if I can point to my (inaccurate) overview earlier today.
Is it meta information update surveys, or is it media playback?
Could you please comment on that?
EDIT: You already did comment with that overview of the i7 cpu usage, which is “nothing”. In consequence, there is probably some features that Roon utilizes on an i7 that is not available on vintage computers like this MacBook Air. Perhaps HW accelleration?
EDIT2: Checking on a Samsung Ativ 9+ i5 the situation is similar to the Lenovo i7, with approx 2-3% cpu when showing GUI. (I had no chance to check this until I completely reinstalled Roon on the Samsung a few days ago as it could not see the core on that MacBook Air. Reinstall AND deleting files helped for that problem)
If nothing else, I can use the Samsung for occasional minimalist playing. Problem solved, but there is an “vintage Macbook air 2009” improvement potential disclosed here, compared to other players. Perhaps a bit on the fringe of top priority after all.
Happy camper!
Hi again,
I don’t believe what I said contradicts what is stated in that link, emphasis is mine:
[quote=Roon Knowledge base]Our Recommendations
Disable background work or wait for it to finish.[/quote]
This advice re switching off background audio analysis is normaly for new adopters running Roon on underspeced hardware with moderate to large libraries … where audio analysis is likely to take days rather than hours.
There is another factor to note as well … the original v1.0 Roon Core handled the audio streaming as well as the administration and GUI functions.
In v1.2 all the critical Audio processing was split out into the “light weight” RAAT process … so it is decoupled from the Core.
However, the advice still stands to get the best sound quality it is advantageous to decouple the DAC from the electrically ‘noisy’ machine running the Core by using a remote RAAT network bridge.
It will be interesting to see how your testing goes on the Samsung Ativ 9+ i5.
Yes, I understand what you are saying, even if I would like to underline that I find disconnecting the power supply from the PC to be the most important of tweaks. It is the same effect as takes place (at least here in Norway with a non-optimal power system) when the lights go down low late at night; the audio quality may finally blossom.
In particular when using the Samsung, the 50Hz hum is audible through the USB cable, which is completely devastating, but oh so common with lousy laptop powersupplies.
The Samsung (ativ) was already reported as similar to the Lenovo, only with i5 performance level of +2%
It might be that your Mac is having an issue or extra overhead with the Mono implementation of the .Net framework on Mac.
Interesting. Generally speaking, I subjectively prefer Windows for audio software. We develop such a strange thing as a Java / Android based audio enhancer that are down to 64 samples latency on Windows because we have made Java ASIO compliant. Cannot do that on Mac (using Java). A parallell story, perhaps.