Daphile - Audiophile Music Server & Player OS

Help Please!!!
I can run Daphile via USB fine but trying to get the boot done via my NUC SSD (dual boot with Windows 10).
Managed to do the following:
1. Create 2 partitions formatted in ext4 named DaphileBoot and Daphile Data (as per Daphile's instructions)
2. Copied the full partioned data from USB to respective partitions on my SSD (hard disk)
2. Created dual boot interface... i.e before Windows start, i can now choose to continue the boot from DaphileBoot partition. Used EasyBCD with Linux Grub (legacy) for Daphile boot entry.

I can boot to Windows fine. But when i choose Daphile partition to boot, it goes back as if switching my NUC up again i.e Daphile never starts.

Anyone can assist Please...
 
I resolved my HDD install issue.
I tried this on a laptop.
All steps were fine. Once i got the livecd to install via firmware setting, Daphile got installed in the DaphileBoot partition without wiping off the HDD.
I was just scared to install as Daphile just shows the Disk drive rather than the partition.
 
DLNA playback

I onto my next extension of Daphile.
Currently I can stream within Daphile server and play files from my NAS server.
I have another laptop from where I want to play music using DLNA (don't want it as a storage server).
I installed MonkeyMedia in the laptop and can see my audio device via Daphile meaning Daphile audio identifiable via DLNA. However I managed to play from files from MonkeyMedia once once or twice only. It does not work as needed and don't know how it worked one off. Anyone tried DLNA function?
Thanks
 
Pre-release with new web UI "File manager" (and kernel 3.16.1) available at:
Daphile ‐ Missing Page

If you have full installation of Daphile, you can upgrade to the pre-release version as follows:

  • press "Install"
  • reboot
Please be careful with the "File Manager". You could easily delete your whole library.

Please send your feedback using the contact form at www.daphile.com.

thank you very much for sharing this info!
This way I managed to upgrade my Daphile 64x (normal kernel) to the Daphile 64bit real Time kernel image


Unfortunately I was not able to install the RT ISO on my Intel NUC right away, only the normal Daphile 64bit ISO worked, by using this alternative method I was able to upgrade



The Real Time kernel sounds much more detailed, has more micro details, I'm using the Audio-Gd Master 7 Amanero DAC
do you also have experiences with the Daphile RT image?
Thanks, for sharing this upgrade info


AudioDandy
Audio Dandy - How to enjoy High Resolution Audio
 
Hi DRONE7,

I'm curious to know if you have ever attempted to use 64 bit version on HP T5740? I think it just wouldn't work because Intel Atom N280 does not support 64 bit,.... Is that correct?

I'm half tempted to try it, but I'm afraid I may end up having to install the i486 version from scratch again.


I'm affraid the Intel Atom N280 is 32 bit only,
https://ark.intel.com/nl/products/41411/Intel-Atom-Processor-N280-512K-Cache-1_66-GHz-667-MHz-FSB

I have the NUC5CPYH Intel NUC (one of the cheapest at this moment) and this NUC has a N3050 Processor which is 64bit
I runs the Daphile 64bit normal and RT kernel perfectly, only DSF streaming is a little bit too much for it, PCM streaming till 24bit 192 kHz goes flawlessly
I use iPeng on my Ipad as remote, and using Daphile daily, I'm very happy with it
 
Daphile RT (Real Time kernel) experiences

Has anybody tested the realtime kernel of Daphile yet?
I'm interested about experiences of people who really tried it on their computer

I hear a big difference between the normal X64-64bit version and the RT image, cleaner more open sound, more micro details, in every recording, more dynamics and definition in the higher frequencies.
I am curious about your opinion! try it

Download link: https://www.daphile.com/firmware/stable/daphile-17.09-x86_64-rt.iso
 
Last edited:
I hear a big difference between the normal X64-64bit version and the RT image, cleaner more open sound, more micro details, in every recording, more dynamics and definition in the higher frequencies.
As they both deliver the same data stream, would you please explain how there can be a difference?

Phofman explained this in detail because he is qualified to know the difference.
 
As they both deliver the same data stream, would you please explain how there can be a difference?

Phofman explained this in detail because he is qualified to know the difference.



I don’t exactly understand...is he qualified to know there is or can be a difference or is he qualified to know there cannot be a difference? And if so in either case...what qualifications are we talking about?
 
I am not any more qualified to know the difference than anyone else. Everyone can learn how his software and hardware really works. Especially in linux where the source code and lots of detailed information (e.g. in alsa-devel mailing list) are readily available.



Thank you very much for your reply.

I am not an expert nor cynical regarding following question;

Did Kipeta develop a RT version beside the regular 64 and 32 bit versions just for fun or other; technical and/or audible differences?
 
As they both deliver the same data stream, would you please explain how there can be a difference?

Phofman explained this in detail because he is qualified to know the difference.

I would like to hear comments of people who realy tried it
Theory is one thing, practice is something else
Please take the effort to test it, then we have something to talk about
 
As they both deliver the same data stream, would you please explain how there can be a difference?
Oh my, over 30 years of digital audio and still talking about this silly argument? :Ohno: :(

Let try to sort it out, once again. Reality check:

Yes, in any properly working (non broken) digital audio system, the data error rate is so small that in practice there are no errors to speak about. Thus YES, the data stream is likely to be exactly the same. Always.

Yet, are you listening to numbers? Obviously not. We can not hear numbers. :D What we hear is an (analog) sound, produced by an analog signal, reconstructed from that data stream.

Now, what many people always seems to forget is that the reconstructed analog signal does not come only from numbers!

The analog audio signal is built by combining the digital audio data stream with two analog signals: a time base (clock) and a voltage reference.

In an ideal world, clock would be perfectly stable and noise free, and reference would be just a pure, noise-free, perfectly constant DC voltage. Thus the shape of the reconstructed analog audio signal would depend only on the data stream content (samples) and would be perfectly repeatable.

In the real world, none of the above conditions are satisfied.

Now, those looks like problems affecting the DACs. What does this have to do with computer software? Apparently nothing. But empirical evidence (=listening) shows that indeed it does.

How? Tough question. Nobody knows exactly. But there are countless different subtle mechanisms which can (indirectly) "connect" the different activities being performed by the computer with different influences ("disturbances") eventually arriving somehow to the clock and/or the voltage reference of the DAC which that computer is feeding.

Clearly, a differently "altered" DAC clock and/or reference implies some difference in the output analog audio signal, and thus possible differences in the perceived sound, too.

That's it. You change something in your computer, even in the software, and the perceived sound (may) change somehow. No matter how perfect and perfetly repeatable is the digital audio stream.

The worst thing is that, obviously, such subtle indirect influences are practically unpredictable. There is basically no way to know in advance what kind of "effect" you may (or may not) get on the sound of a given system by changing something in the computer software (and/or hardware), and it's quite unlikely that a change which produce a certain effect on one system will produce the same result on another. A total mess.


“There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.”


Shakespeare, Hamlet (1.5.167-8)


 
Now, those looks like problems affecting the DACs. What does this have to do with computer software? Apparently nothing. But empirical evidence (=listening) shows that indeed it does.
It is the same computer with the same software, the only difference is the kernel.

Oh my, over 30 years of digital audio and still talking about this silly argument?
Because people keep coming up with silly explanations for things only they can hear. None of these people are aware of Expectation Bias, or, if so, think it doesn't apply to them.

Next time, leave out the condescension.
 
still nobody really tried the RT kernel?
I tried almost everything, because i wanted to experience
it myself: (I use a Audio Gd Master7 DAC with Amanero)

1 Daphile with internal soundcard inbios enabled : warm, dull sound
2 Daphile with internal souncard in bios disabled warm but more transparant sound
3 Audio Linux with soundcard in bios enabled open. transparant sound,
4 Audio Linux with soundcard in bios disabled, no connection with Amanero possible AudioLinux uses alsa for connection Amanero?
I have to test this futher, and upgrade my firmware of Amanero
5 ROON (on Windows)with soundcard in bios disabled, no sound possible, needs
Alsa or WASAPI to make connection to USB Amanero
6 ROON (onWindows)with soundcard enabled, dull. inispiring sound...
7 ROON (on Mac) with soundcard enabled, better sound, more open
but not of the level of Daphile, Daphile sounds more open.
8 ROON server on PC, ROON Bridge on NUC, no connection.possible?
maybe due demo license limitations?
9 JRiver on.Mac , with sound card enabled in bios, great open transparant sound, little bit cold.
10 JRiver Id on NUC (headlesssolution) with soundcard disabled in bios
no connection.possible with Amanero (needsAlsato.makec onnection witusb Amanero?)
11 JRiver Id with soundcard enabled in bios, connection.possible
with Amanero, avarage sound, not as high level as Daphile or JRiver on.Mac
12 Daphile RT on NUC, with soundcard disabled, very open transparant sound, lotts of micro details on every recording, deeper bass, and more authority.
like there is more "space" and "air" between te recordings, very clean sound. the higher frequencies are emphasized alittle bit

i cannot explain what are the reasons of these big differences
but i do hear differences with streaming software on the same hardware
i'm happy that i did these experiments, because now i now
what streaming software works best for me, on.my set
because it all a matter of tuning your entire set, everypart can make a difference
 
But empirical evidence (=listening) shows that indeed it does.

"Evidence" is not sighted listening, but statistically significant positive results from blinded listening test. Please show me a single such result. I have never seen any, only subjective sighted-listening claims. Do you have positive results of a credible repeatable relevant ABX test? That would be something to build on.

How can you fix something you do not know whether it actually exists? How do you get feedback on changes implemented without "measuring" them? I am not saying it cannot exist, even though nobody has ever come with a technical explanation for any CONSISTENT cause. I have just never read of any actual confirmation. Feelings/opinions (sighted listening) are no evidence in this matter.

RT kernel/linux distribution introduces changes to scheduling. It plays key role in low-latency setups - CPU/kernel must keep up with the fast arriving interrupt requests. RT is indispensable e.g. for music production. For pure playback you want latency as large as affordable to minimize the risk of buffer underruns.

Recently I learned about an ARM board / USB DAC combination which throws IRQs every 125us = every USB2 frame = 8k IRQs/s. A regular kernel can hardly keep with this rate reliably, RT kernel has better chances. But that is basically a buggy hardware, nothing common. You want <10 IRQs/s instead.