 
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
|
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
209.95.36.62
In Reply to: RE: "network rendering, streamers, music servers, mini computers" posted by Tony Lauck on December 11, 2014 at 14:14:07
Tony, you claim Ethernet require a considerable amount of computing power and processing. Really now?
A network player, streamer, whatever you want to call it, the size of a pack of cards will have absolutely no trouble streaming a 24/192 WAV, FLAC, or AIFF file. None. That is because it is designed to do nothing else.
I think we continue to chase phantom problems in computer audio.
Follow Ups:
You have to look at peak processing, not average processing. If you transfer the samples one at a time to the DAC then it processes them one at a time. The processing cycles at the sample rate. If you transfer samples a buffer at a time, then the processing takes place each time a buffer arrives. This results in a busy period followed by an idle period at the buffer rate. Given typical packet sizes the cycle time will be in the middle of the audio range, e.g. 1 kHz for USB. The numbers will be similar for Ethernet. Noise associated with this processing may be audible. This is similar to the situation that many people have observed in computer audio where reducing the buffer size improves the sound quality up to the point where buffer overruns start happening and audible glitches appear.
These are real problems. There is a lot of debate about why these effects happen and what the best (or most economical) way of dealing with them might be. However, careful listeners all notice that bits are not bits, or at least usually do not appear to be such. There is spirited debate as to what to do about it. Of course there are people who deny this can happen, but you will find them on other forums.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
I understand what you are saying.
However, explain what kind of noise can affect playback when the computer/NAS never directly interface, and only communicate via a router, and 30 feet of shielded CAT7 cable
Noise can be coupled at least three ways, through the air with cables acting as antennas, through the power wiring and through the signal cabling. You can test (and rule out or rule in) the first two possibilities by running the computer after the streamer has been disconnected from the network. (You may have to fake it out so that it thinks it's still playing, details would depend on system and network.) Shielding on the Ethernet cables will definitely help but there are various ways their effectiveness can be reduced.
Getting to the third possibility, different software in the computer or various hardware related noise will affect the speed at which the computer operates and hence the timing of packets sent through the router. If this timing is different then the router will forward packets to the streamer with different timing. The streamer gets a huge pulse of work each time a packet arrives and the required processing will create noise. If the streamer isn't isolated from the DAC then this noise will affect the audio. This is a good theory, and according to John Swensen, a theory that he has proven to apply in practice.
What this amounts to is that the streamer has a computer inside it and that computer has the opportunity to pollute the audio output of the DAC. I can't think of any way to avoid this possibility other than to isolate the DAC from the streamer. The fundamental problem is that computer components that are designed as digital circuitry are in close proximity with sensitive analog components such as the DACs master clock, converter power supply, DAC chip, IV converter and output buffer.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Thorsten's iFI iUSB creates isolation between computer/streamer and DAC.
What you will hear isn't the computer noise, just the packet processing noise. The timing of packet arrivals will depend on what goes on in the computer. Hence the timing of the packet processing noise depends on the computer. John Swensen has posted about observing this effect. Note: if you change the timing of the noise then the effect on the music will change, hence the listener may perceive differences. To hear consistent sound one will either have to reduce the noise to insignificant levels or time the noise so that it is consistently correlated with the music, or alternatively reduce the quality of the playback by various means such as adding much louder masking noise. This might hide any source differences, but this would not amount to a good outcome.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Yep, John Swenson has called this packet noise (maybe packet jitter?) & it is really the result of the receiver chips self generated noise when packets arrive & processing of these packets occurs. The concept being that this burst of processing causes a current draw on the PS which can effectively result in noise on the PS/ground plane & this noise effecting other parts of the system that are also using this PDN (power Distribution Network).One way of addressing this is to read the whole audio file into local RAM at the DAC & closing down the connection before processing of the audio file from RAM by the DAC chip.
Another way would be to attempt to kill any possible PDN noise when processing this bursty data
Or a final way, might be to ensure the packet bursts do not have a frequency that effects the audio band directly?
Edit: I see my points were already made - sorry for the noise :)
There may be another issue - the signal integrity of the waveform that represents the digital bits? Could a worse SI waveform result in a different sound to a good SI waveform because of similar processing issues in the receiving chip?My thinking is that DACs connected to computers are effected by a mix of 3 possible issues:
- noise conducted via the wire connection (usually common mode)
- bursty packet self-generated noise
- signal integrity self-generated noise
Edits: 12/12/14 12/12/14 12/12/14 12/12/14
Post a Followup:
| FAQ |
Post a Message! |
Forgot Password? |
|
||||||||||||||
|
||||||||||||||
This post is made possible by the generous support of people like you and our sponsors:
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2024, Audio Asylum, all rights reserved ]
