[StanD]

 
​Considering clipped amps ruin drivers I always err on the side of caution by having more power .

If you mean amps that are driven into clipping, then it would boil down to if it is driving your headphones past their max power rating. If not then your headphones are safe, however, you will not be enjoying the music.

 

[Koei]

  If you mean amps that are driven into clipping, then it would boil down to if it is driving your headphones past their max power rating. If not then your headphones are safe, however, you will not be enjoying the music.

​But why is that different for headphones, because speakers don't like an amp being driven into clipping.

 

[Joe Bloggs]

 
If you mean amps that are driven into clipping, then it would boil down to if it is driving your headphones past their max power rating. If not then your headphones are safe, however, you will not be enjoying the music.

​But why is that different for headphones, because speakers don't like an amp being driven into clipping.

The contention is that flattopped waveforms generated by clipping amps produce high levels of power at the harmonic distortion frequencies i.e. treble, and tweeters are ill equipped to deal with the extra power--tweeters generally have lower power handling capacity than woofers.

If you're driving a fullrange speaker or headphone driver, it has a single power handling capacity rating, and this doesn't really change with the frequency makeup.

Multi-driver headphone usually means ultra-sensitive multi-BA IEMs, which you're MUCH more likely to blow up because of overpowered amps than of underpowered amps, simply because of how little power it takes to power them...

 

[StanD]

 
​But why is that different for headphones, because speakers don't like an amp being driven into clipping.

Is it that certain tweeters might have a low power rating and that one might generate too much power for them due to the harmonics generated due to the clipping? In normal music the high frequency content is much lower than mids and bass. Just thinking about it, not necessarily the definitive answer.

 

[Joe Bloggs]

Yes but even that is under contention, e.g. http://audiokarma.org/forums/index.php?threads/clipping-amps-and-blowing-tweeters.570917/

 

[StanD]

Yes but even that is under contention, e.g. http://audiokarma.org/forums/index.php?threads/clipping-amps-and-blowing-tweeters.570917/

I like this answer.
Somewhere there is a discussion at Rane. The general upshot was that it isn't the clipping that usually destroys tweeters, but that when an amplifier is turned up too loud, the high frequency content is increasingly amplified while the volume doesn't increas. For example, with a fifty watt amplifier, the treble content is maybe a few watts. If the amplifer is very over driven, the treble content would increas to 20 or so watts (when the amplifier doesn't have a bass note to clip) and this increase in energy is too much for most tweeters - i.e. its when the amplifier isn't clipping the bass notes that the tweeters get destroyed.

 

[StanD]

This will probably create a Schitt Storm. Got to find my helmet in a hurry.
http://www.head-fi.org/t/538255/sennheiser-hd-600-impressions-thread/17850#post_13340614

 

[dvw]

A signal consists of multiple frequency. A clipped waveform has some DC component to it. An inductor (speakers) appearsto DC as just a wire. So the DC content is what destroys the speaker if it is large enough.

 

[nick_charles]

  True I guess, I was thinking about TCP.

 
yep, TCP when you absolutely 100% have to get every bit correct EVENTUALLY but it is generally considered too sloooooooooooooooow for "real-time" applications. I did a quick search and could not find any **canonical** (or reputable) source suggesting that Audio Over Ethernet implements reliability other than ''it is reliable cos we say so" but I wait happily to be contradicted - but given that bog standard CAT5E is capable of 1000Mbps I am skeptical that better cables would really make a difference...

 

[HotIce]

Not really 100% 

 ... as it is a per packet 16bit checksum.
If you want close to 100%, you need to use stronger checksum-ing at application level.
For Audio, it does not really matter, but if you are sending commands to a Mars rover (for which, you most definitely not use TCP anyway 

) millions of miles away, you really don't want to trust a 16bit checksum.

 

[nick_charles]

  Not really 100% 

 ... as it is a per packet 16bit checksum.
If you want close to 100%, you need to use stronger checksum-ing at application level.
For Audio, it does not really matter, but if you are sending commands to a Mars rover (for which, you most definitely not use TCP anyway 

) millions of miles away, you really don't want to trust a 16bit checksum.

 
I have a question for you re checksums but I'll do it via PM , though not sure my students will like being told that TCP is not really reliable after all but it will make for a killer question for their final..

 

[dvw]

   
yep, TCP when you absolutely 100% have to get every bit correct EVENTUALLY but it is generally considered too sloooooooooooooooow for "real-time" applications. I did a quick search and could not find any **canonical** (or reputable) source suggesting that Audio Over Ethernet implements reliability other than ''it is reliable cos we say so" but I wait happily to be contradicted - but given that bog standard CAT5E is capable of 1000Mbps I am skeptical that better cables would really make a difference...

TCP does not have a speed limitation. It is just a protocol. Howeve, you are right it is not suitable for real time application. The reason is when there is data loss , it will resend AND adjust the transfer rate. So if there is a lot of lost data, the transfer rate will get slower and slower. I was at a technology demo. The guy was showing a video with alot of other traffic. The video was smooth but gets slower and slower. He was cheating by using TCP. If you only watch 10 sec it will be okay but over a longer period then it is not. He sheepishly acknowledged the cheat. Without using TCP, the video becomes jittery. The key is you need better bandwidth allocation and set priority in streaming real time data.

 

[Arpiben]

yep, TCP when you absolutely 100% have to get every bit correct EVENTUALLY but it is generally considered too sloooooooooooooooow for "real-time" applications. I did a quick search and could not find any **canonical** (or reputable) source suggesting that Audio Over Ethernet implements reliability other than ''it is reliable cos we say so" but I wait happily to be contradicted - but given that bog standard CAT5E is capable of 1000Mbps I am skeptical that better cables would really make a difference...

Speed or error corrections are not issues. Latency is the main limitation for real time applications.
Cables,fibers and air (RF transmission)delays signals around a few nanoseconds per meter.
Packetisation / depacketisation meaning the process to convert the signals into packets and vice versa is adding around 2.5 ms per process.
Buffers you may encounter in your signal path are adding latency around 1ms each.
In a point to point audio Ethernet link (not bandwidth shared), the 5-10ms latency is not an issue.
In a shared bandwidth IP network (not audio only dedicated) audio packets latency will vary and have bigger values...
Without congestion, Mobile networks are supposed to have end to end latencies of 10ms (4G) / 5ms (future 5G).
Do note that DACs are also adding a few ms delay with jitter buffers and interpolation filters.

 

[Joe Bloggs]

A signal consists of multiple frequency. A clipped waveform has some DC component to it. An inductor (speakers) appearsto DC as just a wire. So the DC content is what destroys the speaker if it is large enough.

...no?

 

[StanD]

  A signal consists of multiple frequency. A clipped waveform has some DC component to it. An inductor (speakers) appearsto DC as just a wire. So the DC content is what destroys the speaker if it is large enough.

 
 

...no?

@dvw How much DC component? If you integrate an asymmetrical signal you might find some DC offset, I suspect that this should not be an issue in practice. Do you expect to have a very loud pulse waveform that has a crazy duty cycle?