https://www.techtarget.com/searchnetworking/definition/flooding
"...use flooding in denial of service (DoS) attacks to cause a service timeout or to disrupt a computer network."
In other words, when too many packets intermittently arrive all at once in big clumps it can modulate the power supply in a DAC as it responds to the network traffic, which can then cause audible problems. Vaguely seem to recall someone measuring the effect. Don't have a link at the moment though...
"...use flooding in denial of service (DoS) attacks to cause a service timeout or to disrupt a computer network."
In other words, when too many packets intermittently arrive all at once in big clumps it can modulate the power supply in a DAC as it responds to the network traffic, which can then cause audible problems. Vaguely seem to recall someone measuring the effect. Don't have a link at the moment though...
Once had to hook up some DVI to USB video frame grabbers. Each one produced enough USB traffic to require its own USB hub. Added two PCI-E bus USB hubs and connected one frame grabber to each. At that point everything finally worked as it should.
Also, using USB diagnostic tools such as usbdeview or usbtreeview often show more than one USB device per hub. Of course its possible for a USB bus to have variable traffic density due to other traffic demands on a shared hub.
Also, using USB diagnostic tools such as usbdeview or usbtreeview often show more than one USB device per hub. Of course its possible for a USB bus to have variable traffic density due to other traffic demands on a shared hub.
Still audiophile mumbo jumbo. USB bus traffic density variations do not cause any flooding of packets in UAC.
In UAC2 HS data is sent in microframes every 125us. If for some reason host is not able to send data in every microframe there will be dropouts or gaps that should be audible as clicks (or similar). If host is congested for a longer period (several ms) there will be buffer underruns.
In UAC2 HS data is sent in microframes every 125us. If for some reason host is not able to send data in every microframe there will be dropouts or gaps that should be audible as clicks (or similar). If host is congested for a longer period (several ms) there will be buffer underruns.
Last edited:
"...sending large traffic volumes (packet floods)..."
https://link.springer.com/referenceworkentry/10.1007/978-1-4419-5906-5_271
The term packet flood applies to packet traffic levels sufficient to have some disruptive effect on terminal equipment. When packet density variation affects SQ of a dac IMHO that is 'disruptive' to the intended operation of the dac. Regarding terminology, I thought the meaning was obvious enough. If I was wrong about that, its still no justification for getting rude on your part.
https://link.springer.com/referenceworkentry/10.1007/978-1-4419-5906-5_271
The term packet flood applies to packet traffic levels sufficient to have some disruptive effect on terminal equipment. When packet density variation affects SQ of a dac IMHO that is 'disruptive' to the intended operation of the dac. Regarding terminology, I thought the meaning was obvious enough. If I was wrong about that, its still no justification for getting rude on your part.
You still seem to misunderstand. You were not wrong about the terminology but the whole claim was incorrect.
What? That a dac can potentially be affected analog system noise arising from upstream digital traffic density variations?
This is a completely wrong understanding.
Digital traffic cannot influence the decoded analog signal unless the entire layout is designed by a child, or more precisely by someone drowned in audiophile myths.
In the case of errors in the digital signal, the entire decoding is affected and not as a slight noise heard only by some initiates, but a strong noise that will render the analog signal unusable.
A real designer will not make such mistakes, but it seems that we are not talking about design accidents, but about something universally valid.
The audio signal requires only a few megabits of bandwidth to function without errors. On the other hand, a 4K movie requires hundreds of megabytes per second and despite all that it runs without problems on switches of only a few euros/dollars.
As I said before, I have no problem with very expensive equipment as long as I don't have to buy it myself, and those who do buy it admit that they bought it for completely different reasons, not because they are technically better performing (of most of the time they are even bad performing). A very good example is represented by tube amplifiers that are not bought because they would have better performance, on the contrary, but their shortcomings are pleasing to the ears and the appearance is beautiful.
Last edited:
Maybe so for a 12-bit dac. For a 24-bit dac we may be talking about few micro-volts within something like, say, for example, a 3v p-p output.
Ah, that takes me back. I wonder whatever happened to Max Headroom and his magic Goo? He was always entertaining!
He's on record on this site saying it sounded better. Even going into the ADC of the Crown amplifer...
USB and ethernet are very different animals with very different purposes. Something you saw in USB does not translate into an ethernet input DAC.
Let's examine this for a second (and you really are clutching at straws here). For both the magic switches being discussed they have 100BaseT connections to the DAC and GigE ports for everything else. Most recent broadband routers and all modern computers have Gigabit ports. The L2 switch will only sent packets to the DAC intended for the DAC. Now it's possible the GigE side from the server is overloaded with other jobs and that would case packet loss but the L2 device cannot do ANYTHING about that as it's upstream. So if you have this problem there is something wrong with your network not your L2 device.
Remember there are 2 wires for 100BaseT each way. It's full duplex so one twisted pair sends all the data to the dac. One unshielded twisted pair with no ground connection at either end (STP is available but no one has even tried to sell that to audiophiles).
Still waiting for a credible theory here to investigate further.
That is not what you claimed. This is your incorrect claim (in post #15357):
Regarding wired Ethernet noise problems, they appear to be related to things like common mode noise from network gear power supplies, and or sometimes also due to what USB to I2S board sees as intermittent packing flooding sufficient to modulate USB board power supply voltage, which in turn can cause I2S timing jitter.
There is no flooding of packets in UAC as I explained before.
This was a long time ago - for my memory cells at least; even if that's when they were mostly still good.
I believe he was doing pulses in the audio frequency range and claimed nothing happened until he hit volt levels of pulse injection directly onto the op-amps +/- supply.
I suppose he was trying to debunk the PSU noise reduction to vanishing levels some people were working on, the inherent PSRR of the op-amp notwithstanding.
True. He misremembered what we heard and what I reported. He agreed with me at the time. What else can I say?
Bill, Regarding various comments by various people that sort of mishmash ethernet and USB together, my position is still this: People are not always hallucinating. Sometimes they hear some real effect. When they do hear some real effect there has to be some physical explanation. Just because we can't think of a mechanism on the spur of the moment does not justify ridicule and feelings of smug superiority over those that have reported something quite likely real. At the same time we all know that people sometimes imagine things that aren't real. When we have independent reports from different people with different systems, some of whom have described troubleshooting efforts and subsequent resolution, it seems unlikely to me that its all attributable to hallucination.
It seems unlikely to me that there is a single report that is NOT attributable to hallucination.
- Status
- Not open for further replies.