@phofman
FYI. Talking about Moode and referencing Tim.
I'm behind the Moode advanced kernels, which includes the rt-kernel.
And I'm also behind other Moode (audio) optimizations btw!
AND.
You're wrong, on pretty much every aspect.
RPIs are more than sufficient to run audio streams. I'm watching at a CPU load of 0.4% when streaming 44.1/16. At 384k I run 2-3%.
IMO actually a RPI does a better job (under certain conditions) then any PCs I came across - and these are many - at a fragment of cost.
A RPI has a lousy USB port. That's a known fact. But. You can buy an active USB enhancer/filter to get around that and you're still much cheaper then most other systems out there. Again. If you handle a RPI setup with care and you run proper settings and you don't want to make it a high performance server or DSP engine, it'll do really fine. ...and by running high quality I2S HATs you'll get around all the USB mess that exist on any platform.
And NO. Not very many of these small devices - or better - OSes make use of rt-kernels. Just a very,very few!
rt-kernels are like Formula 1 cars. single purpose animals! They have to be treated very carefully. Otherwise you'll end up with XRUNS and system hang-ups - much earlier then when using any other kernel.
Because of the trouble these rt-kernels usually can cause, OS maintainers rather avoid these.
Using a low-latency kernel is a much safer bet! BUT.
If you look for a high performance single purpose animal, an rt-kernel can be a very nice option.
****
Talking about your Odroid issues.
The vast majority of ARM boards faces kernel and driver issues. Kernel maintenance, if existing at all , can not be compared to the RPI kernel development and maintenance. That's one of their major weaknesses.
And that's one of the major advantages running a RPI. RPI delivers kernel and not to forget driver updates on a weekly basis.
Using Odroid and other ARMS put you to a dead-end sooner as you might think -- no matter how good their HW might be. Been there, seen that!
@Julf.
I stopped counting ABXs and double-blinds done and not to forget double-deaf tests for trolls like you.
We even used AudioDiffmaker, with to some people, surprising results!
Folks. Enjoy. I do.
FYI. Talking about Moode and referencing Tim.
I'm behind the Moode advanced kernels, which includes the rt-kernel.
And I'm also behind other Moode (audio) optimizations btw!
AND.
You're wrong, on pretty much every aspect.
RPIs are more than sufficient to run audio streams. I'm watching at a CPU load of 0.4% when streaming 44.1/16. At 384k I run 2-3%.
IMO actually a RPI does a better job (under certain conditions) then any PCs I came across - and these are many - at a fragment of cost.
A RPI has a lousy USB port. That's a known fact. But. You can buy an active USB enhancer/filter to get around that and you're still much cheaper then most other systems out there. Again. If you handle a RPI setup with care and you run proper settings and you don't want to make it a high performance server or DSP engine, it'll do really fine. ...and by running high quality I2S HATs you'll get around all the USB mess that exist on any platform.
And NO. Not very many of these small devices - or better - OSes make use of rt-kernels. Just a very,very few!
rt-kernels are like Formula 1 cars. single purpose animals! They have to be treated very carefully. Otherwise you'll end up with XRUNS and system hang-ups - much earlier then when using any other kernel.
Because of the trouble these rt-kernels usually can cause, OS maintainers rather avoid these.
Using a low-latency kernel is a much safer bet! BUT.
If you look for a high performance single purpose animal, an rt-kernel can be a very nice option.
****
Talking about your Odroid issues.
The vast majority of ARM boards faces kernel and driver issues. Kernel maintenance, if existing at all , can not be compared to the RPI kernel development and maintenance. That's one of their major weaknesses.
And that's one of the major advantages running a RPI. RPI delivers kernel and not to forget driver updates on a weekly basis.
Using Odroid and other ARMS put you to a dead-end sooner as you might think -- no matter how good their HW might be. Been there, seen that!
@Julf.
I stopped counting ABXs and double-blinds done and not to forget double-deaf tests for trolls like you.
We even used AudioDiffmaker, with to some people, surprising results!
Folks. Enjoy. I do.
Last edited:
Do I have to get worried about you?
I said something completely different. Sometimes it's good to read what's been written. I said rt-kernel rather generate XRUNS then getting rid of them!
rt-kernels tend to lock up systems and delay processes on multi purpose platforms. And that's what causing XRUNS.
And 2nd.
Audio optimizations on computers are not about kernels first of all!
The goal is to run the streams as efficient (without great variations) as possible from A to B.
The goal is to limit noise/EMI/RFI generation and voltage/load variations
on that computer.
There are numerous ways to approach this. If a kernel helps. Fair enough.
A kernel would be just a tiny piece of the puzzle.
And again. The better your downstream filters and DACs, the less impact you'll see injected by your upstream equipment. The less impact you'll experience from computer optimizations.
I know RT kernels are problematic, have myself experienced a hard-to-catch bug in ICE1724 driver which appeared only in RT kernel scenario. Why do you use them on moode if they bring the complications and you do not need their fast reaction to avoid xruns?
I try it once more.
If "properly" used inside single purpose environments, rt-kernels can exhibit highest efficiency for a certain process(-chain).
People who use an OS, call it Moode, Daphile or whatever have an option to accomplish this by using an rt-kernel. There's no guarantee that a rt-kernel
will work properly though.
Especially if you plan to use multiple services at once.
People, standard users, who run into problems with their rt-setup and are not able to handle the issues themselves, better switch back to a low-latency kernel or a standard kernel.
However. Modern low-latency kernels do already a pretty good job in getting data from A to B very efficiently. Mechanisms to avoid slowdowns and lockups work quite well on up2date low latency kernels.
An rt-kernel might deliver a little extra spice.
Is it worth it?? Let the user decide for himself and his setup!
Offering several kernel options makes discussions like this rather obsolete.
Enjoy.
Last edited:
Sorry, I still do not understand. What specifically do you call "highest efficiency"? I would understand if it was minimization of xruns risk. I would not understand if it is some "minimization of EFI/EMI" etc.
What specifically does the marketing term "little extra spice" mean? In technical terms please, we are not at an audiophile voodoo site here.
Just google "rt-kernel", and you can learn a lot today.
Enjoy.
I think we just did. Sounds like even you realise the RT kernel doesn't offer any audible advantage, but allowing it as a choice feeds the audiophile mystery.
Or your PC and following front end is Noisy enough for you not to notice the difference ? When difference is big enough, blind tests are too often easily involved ! No need of a blind man to see difference between black & white ! More than often a difference occurs ! And it's not because you don't know how to explain it with your toolbox of known theories than the difference is not exesting ! Deny it because you have not the good intelectual explanation (you may be wrong by a too focused theory which is not seing an interaction you didn't see by theory or you can not able to explain despite the experiment result...) is not fear. And this is the experience in science which is checking the theory ! Not the opposite as you do to have the last word !) In other words, it's not because you are right in your theory than you are not missing Something... you seems to be more a professor than an inventor...if I may ! Not a critic, one needs very god professor to make very good futur inventors).
Last edited:
I just bought an smsl m8a and tried dsd512 up sampling. I was using a i3 7100 which was too slow. However I could upsample dsd512 from ram with hyper threading enabled. I found dsd256 a noticeable improvement on dsd128 and dsd512 similar to dsd256 but I think my PC was suffering.
I am now considering a second machine based on coffee lake. Does anyone have any experience of these with daphile and in particular i3 8100 (4 cores, 4 threads, 6w) vs i5 8400 (6 cores, 6 threads, 65w)? Both do not use hyper threading.
I am now considering a second machine based on coffee lake. Does anyone have any experience of these with daphile and in particular i3 8100 (4 cores, 4 threads, 6w) vs i5 8400 (6 cores, 6 threads, 65w)? Both do not use hyper threading.
Make sure you enter the correct ssid and password. Click refresh to validate the connection. Also not all NICs are supported by daphile so this could be your issue. Use fing on the smartphone to check the list of devices.
Yes. Just configure daphile to upsample to DSD. Unfortunately everything gets upsampled. The only exceptions are DSD encoded files with the option to upsample only pcm.
Re the upsampling of streamed media I loaded a radio station and checked the transcode log file which implied the 'streamed media' was indeed being upsampled. I assume the same for Tidal since it is processed much the same way. Likewise my DAC displays DSD128.
[Decode] -F aac-wav-daphile-* -m xx-xx-xx-xx-xx -p daphile -f wav -
Clock: 09:48:03.895
Source: Proxied stream from Media Server
Input format: AAC, 44.1kHz, 16bits
SoX effects: [gain -6.6]->[rate -vLsn 5644800]->[sdm -f clans-8]->[dop]
Output format: DoP WAV (S24LE), DSD128
[Decode] -F aac-wav-daphile-* -m xx-xx-xx-xx-xx -p daphile -f wav -
Clock: 09:48:03.895
Source: Proxied stream from Media Server
Input format: AAC, 44.1kHz, 16bits
SoX effects: [gain -6.6]->[rate -vLsn 5644800]->[sdm -f clans-8]->[dop]
Output format: DoP WAV (S24LE), DSD128
See Adding Pandora to the LMS Menu - What am I missing?
You need to add your mysqueezebox.com logon details on the settings / advance media server settings / mysqueezebox.com tab.