Knowing that we can do all the measurements isn't a superstition it's the reality and if you can't understand you need open your mind.
What measurements we can't do..Knowing that we can do all the measurements isn't a superstition it's the reality and if you can't understand you need open your mind.
I'm open minded for your arguments..
You can't do the measurements that you don't know
If you believe that you know all measurements the science can't advance like you.
If you believe that you know all measurements the science can't advance like you.
I'm out..You can't do the measurements that you don't know
If you believe that you know all measurements the science can't advance like you.
Too deep for me..
I want to thank Kipeta for offering such a nice stable package. Wonderful job!
I tossed the latest posted 64bit release on a lil' dell optiplex atom - ethernet over the network to a WD MyCloud containing FLAC and an itunes library. Works awesome, and sounds pretty good even with the Behringer U-Control as a temporary DAC.
One suggestion for the future, maybe make the controls bigger (play, fwd, rwd, etc) bigger for fat fingers. I'd still love it if you didn't! Great Job
Question for all. there are tons of info out there, but the market changes fast. Can you recommend a currently available quality USB->I2s converter out there right now. Probably looking for a less expensive unit. I'm only doing 16/41 now, but it would be good to be future proof. TIA
I tossed the latest posted 64bit release on a lil' dell optiplex atom - ethernet over the network to a WD MyCloud containing FLAC and an itunes library. Works awesome, and sounds pretty good even with the Behringer U-Control as a temporary DAC.
One suggestion for the future, maybe make the controls bigger (play, fwd, rwd, etc) bigger for fat fingers. I'd still love it if you didn't! Great Job
Question for all. there are tons of info out there, but the market changes fast. Can you recommend a currently available quality USB->I2s converter out there right now. Probably looking for a less expensive unit. I'm only doing 16/41 now, but it would be good to be future proof. TIA
for an overview of usb - > i2s see the ranked list at the end of the gustard u12 head fi forum - Gustard U12 USB Interface 8 Core XMOS chip | Page 244 | Head-Fi.org.
Hi all,
I like Daphile very much, i'm using it with a Audio-Gd Master 7 DAC with Amanero Combo384, i have installed Daphile on a Intel NUC (Celeron) 8 Gb Memory + 120 SSD
I works very good PCM playback till 32bit 192 KHz is flawless (for DSD this NUC is a little underpowered)
Today i noticed the Real Time kernel, and I'm eager to try it, but after installation on the SSD, and booting it for the first time i get: INIT: no more processes left in this runlevel
and than it hangs on this.
I'm using https://www.daphile.com/firmware/stable/daphile-17.05-x86_64-rt.iso
Can anybody help me?
Thanks in advance
Audio Dandy
Audio Dandy - How to enjoy High Resolution Audio
I like Daphile very much, i'm using it with a Audio-Gd Master 7 DAC with Amanero Combo384, i have installed Daphile on a Intel NUC (Celeron) 8 Gb Memory + 120 SSD
I works very good PCM playback till 32bit 192 KHz is flawless (for DSD this NUC is a little underpowered)
Today i noticed the Real Time kernel, and I'm eager to try it, but after installation on the SSD, and booting it for the first time i get: INIT: no more processes left in this runlevel
and than it hangs on this.
I'm using https://www.daphile.com/firmware/stable/daphile-17.05-x86_64-rt.iso
Can anybody help me?
Thanks in advance
Audio Dandy
Audio Dandy - How to enjoy High Resolution Audio
Apparently the init process died. I do not think you can do much about it, apart of hacking the system you have downloaded.
Why do you need RT kernel? It is not needed for basic music playback at all, in fact some drivers can experience problems in RT kernel. RT is important for low-latency sound required for music creation (recording, mastering, etc.).
Why do you need RT kernel? It is not needed for basic music playback at all, in fact some drivers can experience problems in RT kernel. RT is important for low-latency sound required for music creation (recording, mastering, etc.).
I have installed the latest beta RT version, and this version worked!
Daphile is rescanning my music library now....
Daphile is rescanning my music library now....
Apparently the init process died. I do not think you can do much about it, apart of hacking the system you have downloaded.
Why do you need RT kernel? It is not needed for basic music playback at all, in fact some drivers can experience problems in RT kernel. RT is important for low-latency sound required for music creation (recording, mastering, etc.).
AudioLinux also uses a RT kernel, because of the better latency, for Audiophile playback this would be better sounding, I just installed the Latest Daphile RT beta version (that seems to work) I will test it now to see if the RT kernel sounds better on my set
AudioLinux also uses a RT kernel, because of the better latency, for Audiophile playback this would be better sounding
How can "better" latency make it "better sounding"? In fact lower latency = higher CPU load/more CPU wakeups (sound card IRQs must be served more often), i.e. the exact opposite of the usual goal of minimum load/consumption/noise.
Author of Audiophile Linux (originally regular ubuntu with a few installed/uninstalled packages and skins, now archlinux) understands the words audiophiles want to hear, therefore he is serving them their sweets. The audiophile voodoo is applicable in linux world too.
I'm listening now to the latest Daphile RT image,
on my loudspeakers PureAudioProject Trio 15 Voxativ i can hear a huge difference compared to the normal Daphile image.
I didn't expected that the difference would be so big, It's like if the quiet passages in a music piece are more quiet, and therefore the dynamics are much
foreward, it's difficult to describe, but it's likethe Amanero can play now much clearer.
The bass is indeed more deep, more tight, and there are more details in the highs.
But what i likethe best is the fact that the music has more authority, more speace between the quiet passages.
Normally you hear this only on expensive dCs or Nagra DAC's
I have been listening to serval streaming software solutions lately ROON, JRiver and Daphile,
But this new RT Daphile image realy impressed me big time
I will write a image about it tomorrow on my website, were I will write my experiences so far (I didn't have tested AudioLinux yet)
But this RT kernel image rocks! I can recommend to try it at least to listen if
you like it better than to old one
on my loudspeakers PureAudioProject Trio 15 Voxativ i can hear a huge difference compared to the normal Daphile image.
I didn't expected that the difference would be so big, It's like if the quiet passages in a music piece are more quiet, and therefore the dynamics are much
foreward, it's difficult to describe, but it's likethe Amanero can play now much clearer.
The bass is indeed more deep, more tight, and there are more details in the highs.
But what i likethe best is the fact that the music has more authority, more speace between the quiet passages.
Normally you hear this only on expensive dCs or Nagra DAC's
I have been listening to serval streaming software solutions lately ROON, JRiver and Daphile,
But this new RT Daphile image realy impressed me big time
I will write a image about it tomorrow on my website, were I will write my experiences so far (I didn't have tested AudioLinux yet)
But this RT kernel image rocks! I can recommend to try it at least to listen if
you like it better than to old one
Expectation Bias?
I had to look it up, because i didn't what this meant, i can tell you the difference with the new (latest) 17.07 - B1111525-x86-RT image and the non-RT image are HUGE
I let other people listen to the new streamer, and they noticed the same.
it's not between the ears this something you can you can easily experience yourself, the sound has less "jitter" and sounds crytal clear....
AudioLinux wrote a article about it, they could even proof it, that RT images are better for the audio: AudioLinux - The audiophile realtime plug & play operative system
They compared AudioLinux OS with Windows 10, and AudioLinux RT had much less latency that you can proof with an oscilloscope
I had to look it up, because i didn't what this meant, i can tell you the difference with the new (latest) 17.07 - B1111525-x86-RT image and the non-RT image are HUGE
I let other people listen to the new streamer, and they noticed the same.
it's not between the ears this something you can you can easily experience yourself, the sound has less "jitter" and sounds crytal clear....
AudioLinux wrote a article about it, they could even proof it, that RT images are better for the audio: AudioLinux - The audiophile realtime plug & play operative system
They compared AudioLinux OS with Windows 10, and AudioLinux RT had much less latency that you can proof with an oscilloscope
zerrax, it is called Expectation Bias, ie, you are kidding yourself.
Did you test the latest RT beta image yourself?
You can't do the measurements that you don't know
If you believe that you know all measurements the science can't advance like you.
I find this a very goood optimistic
statement.
AudioLinux wrote a article about it, they could even proof it, that RT images are better for the audio: AudioLinux - The audiophile realtime plug & play operative system
They compared AudioLinux OS with Windows 10, and AudioLinux RT had much less latency that you can proof with an oscilloscope
You are mixing two issues.
Of course, RT kernel has lower latency in serving IRQs. You do not have to make any measurements, it is the main purpose of the RT patches.
But lower latency in serving IRQs has no effect on timing of the data stream going to the soundcard (jitter of audio samples) as it is timed by the soundcard itself (PCI/e) or the USB controller (USB soundcard). The transfer of samples from memory buffer is performed by DMA transfer, the CPU is not involved in the transfer at all.
If someone claims his playback software is sonically better because IRQ latency is lower, he is only (I hope unintentionally) misleading his users. No wonder there is a price mentioned on that report...
You are mixing two issues.
Of course, RT kernel has lower latency in serving IRQs. You do not have to make any measurements, it is the main purpose of the RT patches.
But lower latency in serving IRQs has no effect on timing of the data stream going to the soundcard (jitter of audio samples) as it is timed by the soundcard itself (PCI/e) or the USB controller (USB soundcard). The transfer of samples from memory buffer is performed by DMA transfer, the CPU is not involved in the transfer at all.
If someone claims his playback software is sonically better because IRQ latency is lower, he is only (I hope unintentionally) misleading his users. No wonder there is a price mentioned on that report...
Soundcard? in an audiostreaming solution?
A soundcard is something of the 80's when connect little speakers (or headphone) on your PC
Now streaming goes directly by USB through your DAC
The computer (in my opinion) is not even allowed to touch, alter the music data.
That is the domain of the DAC.
The (streaming) PC is only allowed to transport the music from the NAS to the DAC.
So because DSD, DXD files are rather big, speed is important.
Because streaming through USB is Asynchronous, speed is very important
The clock in the DAC tells the PC on what time the packages should be sent etc.
Therefore a fast operating system that can handle the transport of the music packages is a must.
|Realtime operating systems are therefore very welcome, because they have proven (not by measurements but with my own ears) that they sound better
Read my review for more info:
Audio Dandy - How to enjoy High Resolution Audio
Soundcard? in an audiostreaming solution?
A soundcard is something of the 80's when connect little speakers (or headphone) on your PC. Now streaming goes directly by USB through your DAC
Every soundcard has a controller and a DAC (some have them combined into one chip). USB soundcard has a USB receiver chip/controller and DAC. Some people call it just USB DAC. USB soundcards are not much different from PCI soundcards, both are handled by alsa subsystem in linux. Only the very lowest driver layer differs...
Very true. Then how can change the "audible quality" if it supplies the very same samples and timing is controlled/provided by the soundcard clock?The computer (in my opinion) is not even allowed to touch, alter the music data.
That is the domain of the DAC.
The (streaming) PC is only allowed to transport the music from the NAS to the DAC.
So because DSD, DXD files are rather big, speed is important.
Unless resampling to PCM, streaming DSD/DXD files requires no major performance - even DSD512 is only 25Megabits/s, i.e. only 3MB/s.
Because streaming through USB is Asynchronous, speed is very important
The clock in the DAC tells the PC on what time the packages should be sent etc.
Therefore a fast operating system that can handle the transport of the music packages is a must.
What? Please learn how the USB async audio works. The PC keeps sending samples in every USB frame, just like in adaptive mode. Only the USB async controller (not the DAC, the USB receiver controller) keeps sending feedback messages which tell the driver to put slightly more samples/less samples into new frames being prepared into RAM for the USB controller to later transfer to the soundcard over DMA when its their time in the row. So the usb-audio alsa driver will not copy 48 stereo samples into the location of the frame in memory (for stereo 48kHz adaptive, frame every 1ms), but based on the feedback messages it copies e.g. 47 or 49 samples. In fact it will copy 48 samples most of the time - look how little the momentary freq number listed in /proc/asound/cardX/stream0 differs from the fixed frequency (BTW did you know about this very useful proc file?)
The async controller puts samples into a buffer, since the feedback is delayed by the alsa period time (when the driver receives the feedback message, there are already many frames prepared in RAM for the DMA transfer. The change will affect only new ones - thus the delay. As a result of this feedback, the USB receiver receives on average just enough samples to keep the buffer filled optimally when read by exact clock by the DAC.
Realtime operating systems are therefore very welcome, because they have proven (not by measurements but with my own ears) that they sound better
?? Proven just by sighted listening? You are joking, right?
The RT OS reacts faster to IRQ requests. If a regular OS has enough time to fill new data into RAM buffer for the USB controller to read over DMA, faster reaction brings nothing - the data will just wait a fraction of millisecond longer in the RAM - e.g. 5.5ms instead of 5ms.
If the system does not deliver the audio samples on time, it produces audible glitches/cracks. In alsa this is called xruns. No way could it change the audible "quality" of the music - highs, lows, etc.
But this has been said here so many times, yet the uninformed voodoo lives for ever...
- Home
- Source & Line
- PC Based
- Daphile - Audiophile Music Server & Player OS