PowerSave Plugin for Daphile
I've edited Jason Holtzapple's PowerSave plugin for control the power state (power off client, shutdown or suspend server) after selected time period - either inactivity or all the time.
With this plugin, you can shutdown/suspend server after a specified time.
Link to repo: https://dl.dropboxusercontent.com/s/dfprmucpwg1dlpy/pluginrepo.xml
Image:
I've edited Jason Holtzapple's PowerSave plugin for control the power state (power off client, shutdown or suspend server) after selected time period - either inactivity or all the time.
With this plugin, you can shutdown/suspend server after a specified time.
Link to repo: https://dl.dropboxusercontent.com/s/dfprmucpwg1dlpy/pluginrepo.xml
Image:
Attachments
Last edited:
Since audio playback is a non realtime application a RT kernel will operate in the same manner as normal kernel. A modern day multicore CPU will be waiting for something to do as it can spread multiple tasks and processes over many cores.
Think about a desktop operating system, it can perform multiple tasks at the sametime without the need for a RT kernel.
Audio playback is not a intensive application for a cpu even for a small embedded computer like a raspberry pi.
The kernel type doesn't set the audio quality. Ultimately audio quality will be determined by the attached USB DAC.
Think about a desktop operating system, it can perform multiple tasks at the sametime without the need for a RT kernel.
Audio playback is not a intensive application for a cpu even for a small embedded computer like a raspberry pi.
The kernel type doesn't set the audio quality. Ultimately audio quality will be determined by the attached USB DAC.
Hear hear! I wish people who disagree would provide some actual evidence for their claims, but I have been asking for that (in vain) for at least 5 years now...
I understand this to some extent, but this is reversal of the question. All things being equal, why would one NOT install the RT version ? Some people 'claim' the RT version sounds (markedly) better than the non RT, some people claim there is or can be no difference. I have not yet read about anyone claiming the non-RT sounds better.
So again, why would one NOT install the RT but the 'normal' version.
Last edited:
If someone claims A sounds 'better' than B who are you to claim this is not so and to demand 'proof' that what they say is true ?
It's an entirely subjective matter. It's like saying red is prettier than blue. You could claim there is no 'difference' between the two you would be absolutely right. Still, I don't like blue Ferraris or red Subarus. Regardless of paint thickness, density, reflectiveness or whatever other 'measurable' physical property you would care to measure.
You could tell me there is no objective difference I'd probably agree. If you tell me I should like them both equally I would tell you to fork right off.
Unless you have some application or process that needs to get the attention of the cpu to carry out a specific instruction at a particular time without delay then that is what a realtime kernel will do for you. Audio playback is not one of those processes.
As I explained in my previous post, a kernel realtime or not, does not and can not affect audio quality. This is a myth propagated by audiophiles who don't want to undertake research or are ignorant on why things function the way they do.
The technical functionality of a linux operating system is not subjective.
As I explained in my previous post, a kernel realtime or not, does not and can not affect audio quality. This is a myth propagated by audiophiles who don't want to undertake research or are ignorant on why things function the way they do.
The technical functionality of a linux operating system is not subjective.
That is exactly my point. Not everything is subjective, and there are true and false statements. Red is not the same as blue, and of course people have different color preferences. On the other hand, laiming that red cars have a much higher top speed than blue ones would require proof.
By editing my quote you have misrepresented the 'jist' of my statement to suit your prejudice. I find it dishonest.
Shirley this works both ways. If there is no objective reason to choose the RT version, there is equally no objective reason to choose the non-RT version ?
I did not change anything you wrote. I only quoted the relevant part instead of quoting the whole message - that is normal practice (and in fact quoting the whole message is usually frowned upon).
Julf (owner of 5 landies)
There actually is. There is a good reason the kernel is not RT by default - the non-RT kernel works much better in any non-hard-realtime applications (and again, playing music is *not* a hard real time application).
From a logic perspective then yes. However it is not totally correct. There's no benefit in using a RT kernel for audio playback, apart from some weird audiophile psychological pleasure from doing so.
Engineers will use a RT kernel if they have a particular use case to execute a process at a given point in time that takes priority over other less important processes. The kernel doesn't play any part in modifying a audio signal, that task is carried out by other software modules within the linux operating system.
Julf is also correct.
Last edited:
You see what I did there ? I just deleted the few last words of you sentence, but I now claim I did not change anything to the statement.
I have gone in search of a few of your posts, and in my opinion you are a 'pseudo scientist', otherwise known as a quack. In a nutshell you keep demanding proof of people's subjective claim that A sounds better than B.
In itself this is not 'wrong' (did you notice the quote there ?). The actual scientific method, however, is to develop a battery of tests that are agreed to provide a set of results by which it can be determined whether a statement is 'true' or 'false'. In other words, you are requiring the maker of the statement not only to provide proof, but also to provide the proof that the result of the objective method which they employed is unequivocal proof and/or confirmation of their subjective experience. So without agreeing upone a framework by which the test results are judged the question is in equal parts useless and -again- dishonest.
And landies are crap
Last edited:
Ok, let me try a different approach here. What would be the advantage of using the non-RT kernel version of Daphile over the RT kernel version. I have possibly assumed falsely there would be other (functional) differences between the two bar the kernel, as a result of having used a different kernel.
So? I have no problem with your quote.
Wow, that turned into ad hominem rather quick...
...followed by a straw man argument.
I don't care about your subjective perception or experience. What I care about is if you can, in reality (as opposed to in your head) really hear a difference. Easily verified with a controlled, double blind ABX test.
I have explained the differences between the two types of linux kernel across multiple posts, you have asked the same question in different ways, it's obvious that you want me to give you an answer to what you want to hear, in other words you want me to confirm that one type of kernel will sound better, different or worse than the other. That's not how it works.
A RT Linux OS will be compiled differently along with other software modules that also need to be modified for RT operation.
This Linux RT Kernel for audio playback is typical audiophile mythology, I have explained why it makes no difference, yet it appears you don't want to hear this as it appears to conflict with your preconceived notions that it must make a difference.
I am explicitly (at least I thought I was) NOT asking about 'sound' differences between the two, but rather if there are any other reasons to choose either. ? In (yet again) other words, does the use of different kernels have any other consequences in usability/functionality NOT RELATED to objective or perceived sound quality.
But I see
Although I must admit I do not undertand why it should. Which does not mean it is not a factual statement.
But I see
Although I must admit I do not undertand why it should. Which does not mean it is not a factual statement.
Last edited:
Daphile and tags
I hate to break up this rather heady conversation with something a bit more mundane, but I'm having a problem with tags and cover art on my Daphile server. I have a mix of MP3, M4A, Opus, and FLAC files and on some the cover art doesn't show consistently - it's there one minute, gone the next. Opus files may not show their tagging info at all. I use MP3Tag to do all my tagging. Can anyone offer any insight?
I hate to break up this rather heady conversation with something a bit more mundane, but I'm having a problem with tags and cover art on my Daphile server. I have a mix of MP3, M4A, Opus, and FLAC files and on some the cover art doesn't show consistently - it's there one minute, gone the next. Opus files may not show their tagging info at all. I use MP3Tag to do all my tagging. Can anyone offer any insight?
When I first noticed this I thought I was imagining things. It was during my intitial build and testing phase where I had pointed to a network storage location with very few albums in it. I haven't really gotten into it, but I have the impression that when Daphils 'rescans' the storage for new content, it 'loses' old art but often also finds 'new'. Not as in newly added files, but existing ones where there was no art before. I have also noticed that scanning or rescanning can take an increadibly long time depending on quantity and network speed and probably processing muscle of the player). I usually only switch it on, listen for a while and switch it of again, which may adversly affect matters. But I'm now building a new box, and I'm going to leave it on for a few days to give it ample opportunity to 'catch' everything'.
Last edited: