A wild guess about what Miero is saying is that OSFBypass disable those noise shaping functions for delta sigma dacs that help for objective measurements.
Still, it may or may not sound subjectively better
+1 for this subjective test (with native high-resolution material)
Synchronous clocking as used here may obviate the need for this type of pre-processing in OSFBypass mode?
Last edited:
I've not tried this, but I don't think so.
BTW: related posts to DAC thread: http://www.diyaudio.com/forums/digi...e-reference-dac-8-channel-77.html#post3868758
BTW: related posts to DAC thread: http://www.diyaudio.com/forums/digi...e-reference-dac-8-channel-77.html#post3868758
Yes, I would like to hear some (subjective) results in the present era.
On the contrary, over the past 5 years or so I have consistently heard credible reports that network access of music files (whether "streaming" or not) beats local file access. Recently, someone explained that computers do a better job of media file playback when freed from the task of controlling a mass storage device. This may, or may not, be correct, but either way the anecdotal results remain.
The only way I can see how it would make a difference is if there was also some accompanying physical element to it too. Eg: you were running wired ethernet to a noisy network device and didn't have any isolation. I spent a while tracking down a horrid low level interference in my dac a while back and moving to wifi rather than a wired solution totally cleared it up for me. I suspect an Isolator would have helped too.
Otherwise, this is the digital domain surely? Data is data and there can't be any way in which the sound file data a player receives is any different depending on the method of storage and retrieval. The whole world of data and digital tech depends on it. If the bits of data are any different, it's a failed data transfer. There's built in error checking and retransmission in all popular file transfer protocols, whether they're using a local storage device or a huge network of cables and large distances. It makes no difference to the data content whether you view an image file from your local hard drive or via the Internet from the other side of the planet, the 2 copies will be identical.
I don't think anyone is arguing about data transfer being correct in terms of the same bits being received as were transmitted, but it's what you do with the bits that is important in music. There is a fundamental difference between assembling the correct bits to create a static image file and playing music, which is constantly dynamic and where timing is everything.
Ray
Yes, this is it, the jitter aspect!
Ray, now that you are in orbit, puts you in a good position to test this case
Last edited:
Sure, but that conversion of music file into a musical i2s signal for example is the job of the player and that part stays the same regardless of the method of storage and delivery doesn't it?
All I'm suggesting is that as long as the player has access to the file data in a timely fashion with no delay or interruption, I don't see how it can make a difference whether it's fetched from a local drive, across a local network or indeed over the Internet from the other side of the planet, unless there are other external physical factors at play that go along with that method like I found with my noisy ethernet power plug.
The problem is Players may choose to "play on" even if data is slightly fouled, using some sort of padding or correction - so you hear less than favourable results
Makes a lot sense, but I am also thinking data needs to be marshalled across various layers during network access and this creates similar or even worse latencies depending on how the network is setup?
Also, please educate me with this concept: mapping or mounting a network drive for data transfer involves using some sort of OS specific mechanism like "Named Pipes" that is more direct as opposed to streaming technologies like UDP/TCP as used in DLNA/UPnP devices?
Last edited:
Yes and no; the physical device may be the same but remember that we don't use real-time processing on out little computers so they time slice in order to perform multiple tasks, apparently all at once. It is quite possible that there is some small variation depending on the playback method in use.
Ethernet is a free for all and relies on collision detection and retransmits and performance degrades as load increases.
Just a quick couple of possible sources of variation and certainly not intended to be in any way definitive.
Ray
well, yes and no... If there's a problem with transmission bandwith or serious interference, then yes, there will be glitches, pops and crackles to the sound as the player will try to carry on regardless.
But assuming that the bandwidth is sufficient and consistent enough, at this stage in the process (transferring files across a network or a data bus like from a hard drive to the player) we're talking about file transfer control protocol. This includes layers of error checking and data validation and the possibility to retransmit and re-order errored packets of data, so you shouldn't be able to get a fouled version of the file.
It's not the same as tuning an FM radio to a transmitted signal or even sending an i2s data signal down a wire and hoping that the dac at the other end receives it in tact where it's possible to make it better or worse. It's constantly checked for accuracy backwards and forwards and it's either 100% correct or not. So unlike other parts of the audio chain, you can easily monitor the quantity of errors and the integrity of the data because the protocols report this. If there's no issues with delivery failures, then the signal must be 100% accurate. You can't buy a better network or hard drive cable and make it sound better if the checking protocols report that there are no delivery failures.
So unless people are experiencing differences in sound caused by other external issues associated with each method like ground loops from network cabling, interference from hard drive motors (is that a thing?) or such, I don't see how it's possible to have a difference in the ultimate sound output from the method of file delivery to the player.
apologies if that's a bit longwinded and seems a bit condescending / ranty
James
I have the same thoughts. The collisions and ethernet degradation will result in increasing latency, NOT bad network messages. Look at the network stack:
The TCP/IP Guide - NFS Architecture and Components
I think all the players would be at the application layer(s), by the time the data message reaches that level of the stack, the previous layers have assembled the packets, ordered them correctly and error checked them (checksums) and decided whether it's a keeper and handed it up or it's a looser and requested a resend. The issue would be what the application does if there is a missing data message, because at that level of the stack it will either have a good message or no message at all.
Is UDP used at all for any audio stuff? I doubt it, it's used for simple messaging because it is connectionless, therefore makes no gurantee that a sent message makes it to the reciever, and if the messages do make it, no order of arrival is guaranteed.
A fast disk in a fast computer will most of the time be faster than a network access, less overhead, more predictable latencies. Add the use of cache and raids, not to mention SSD and you can see why. The question for me is when is network shared access using say a gig network with jumbo frames in a normal home network traffic (not a congested office) using dedicated computers (NAS/music players) reach the point where latency becomes a factor?
If that is any issue, then it's one with a pretty simple solution?
Surely most players will buffer the music data locally as standard to some extent before rendering it as I2S? As long as the device has the memory and processing power to handle a larger buffer value, would that not negate any timing issues with the general file transfer to the player?
My guess is it doesn't. Does anyone know actual the network bandwidth required to stream uncompressed 16/44k and 32/384k audio files?
For less serious degradation, noise is end result of this play on mode Not much of an issue with typical lifestyle systems but not up mark at an audiophile level
I2S data are clocked by external master clock (not Ethernet, or USB or SD card) and they have to be (and they of course are) prepared in the audio HW buffer, otherwise you would hear it as click/pop or see on FFT of audio output as short-term noise level jump.
Do you observe any of this? If not, then (digital) audio quality in slave mode of I2S source depends only on the design/precision/jitter/EMI/isolation/quality/... of elements between I2S source and the DAC.
Do you observe any of this? If not, then (digital) audio quality in slave mode of I2S source depends only on the design/precision/jitter/EMI/isolation/quality/... of elements between I2S source and the DAC.
Totally agree with this, with all the bufferring, isolation and re-clocking to low jitter ref clock we should not see any difference whatever the transport mechanism. But then again, we need to look at Chanh's results with BBB that seemed to favour locally served data... so the investigation continues ....
My comments in post 1743 have been extrapolated into other subject areas; data integrity and jitter.
So to be clear, my original comments were unrelated to these issues, at least in intent.
I was talking about the performance of the computer hardware in combination with its audio playback application, and how this has been reported, anecdotally, to be better when the same computer does not have to perform certain other tasks. Accuracy/integrity of the audio data is a "given" in this context, and is unlikely to be related.
I don't offer a reason why, because I don't know. I'm passing on the observations from other credible sources that I have gleaned over 5 years or so.
Acko's own Edel renderer, as a point of interest, fits this device profile.
Music Player Daemon, for example, has a configurable buffer setting. The default setting is 2048 kB. Most other audio playback applications also have inbuilt buffering, but this buffer may be hard-coded.
If latency/buffering concerns you, you can even configure your playback application to pre-cache each entire audio track into RAM before playing it. I have tested this with MPD, it typically adds a 2 or 3 second delay before each track is played.
So to be clear, my original comments were unrelated to these issues, at least in intent.
I was talking about the performance of the computer hardware in combination with its audio playback application, and how this has been reported, anecdotally, to be better when the same computer does not have to perform certain other tasks. Accuracy/integrity of the audio data is a "given" in this context, and is unlikely to be related.
I don't offer a reason why, because I don't know. I'm passing on the observations from other credible sources that I have gleaned over 5 years or so.
Acko's own Edel renderer, as a point of interest, fits this device profile.
OK, now we're on this subject, yes, I agree. Data is typically shifted through networks in irregular chunks. The thing that helps us is that, unlike mobile telephony, we don't care about realtime response, and we're happy to tolerate a certain amount of latency as the system(s) buffer the data for us.
Music Player Daemon, for example, has a configurable buffer setting. The default setting is 2048 kB. Most other audio playback applications also have inbuilt buffering, but this buffer may be hard-coded.
If latency/buffering concerns you, you can even configure your playback application to pre-cache each entire audio track into RAM before playing it. I have tested this with MPD, it typically adds a 2 or 3 second delay before each track is played.
Not only locally served data has proven to sound better, but also I found using SSD powered by a linear ps further improving the sound! Again, how to convey this exclusive experience? After all, audio is so subjectively perceived, and there are endless of combinations/permutations which collectively effects the final result.
Did you know changing Ethernet cable to better grade will also improve the sound?
Yes, you might laugh out loud from reading this...., I put the money right where my mouth/words are!
Did you know changing Ethernet cable to better grade will also improve the sound?
Yes, you might laugh out loud from reading this...., I put the money right where my mouth/words are!
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.