Everyone has now given into the fact that you need more complexity to get higher performance per clock.
Evidence of this: The multiple-logical-core (see Aurora, Intel HT, EPIC, Power5) trend is the next step in complexity beyond pipelining and predictive execution/caching.
Do you hear anyone referring to AMD64 as "K8"? I hear AMD64, x86_64, Opteron, Athlon64, but never K8 (maybe once or twice, to relate how similar the FX, Athlon64 and Opteron are)
So we'll call it K9 in the same way we call PentiumPro/II/III all i686. And no one will get the dog jokes, except us, and maybe 4 readers and 1 of the creators of Penny Arcade.
How many of these are burning 600 watt power supplies just to power all the glo- wire and eye candy?
None. A hard drive will require more power than a case with the monetary equivalent ($100-$200) worth of ultra-brite LEDs.
And I will wager that less than 10% of current computer owners in the US are even wont to open their cases, and a much smaller number will actually want to spend the money on lights and racing stripes.
His comment did not warrant a response as it was vacant of anything resembling an argument or relevant observation.
By throwing in the word "fag", he gets the attention of trolls who would love to start a flamewar.
Is there room on Slashdot for trolls who troll the trolls? Metatrolling?
Also, it is not also polite to not judge a person by the clothes that he wears? Hygiene is a necessity, not an aesthetic, hence it is a poor analogy you make.
This post is going nowhere. I think I'll just cut...
by the biggest dicklicker on Slashdot, Sir Sucks-a-lot.
You copied the PUBLISHERS' blurb. No wonder it was positively glowing.
I recommend not buying the book because it's as full on "insight" as this loser's posts. It's only 6 chapters long, and if it was really going to convicne me it'd have to be a lot longer and features twice as many references. Just pointing things out that go with the author's pet theory does not a good argument make.
Is the Canopy group the ugly face of some kind of parasite which feeds on the Internet and technology? Everything they touch smells like death and decay.
I wish Trolltech would throw them off so I can believe there's not some kind of sinister connection beneath the surface.
Some of them support syslog, which is not really much help to Windows people and a bit arcane for a lot of Linux people.
Gee-whiz, I mean syslog isn't like this CORE service of every modern Unix: why not learn how to use it? Arcane. Hardly. Essential is more like if you give a damn about your system. I mean, do you not use the Event Viewer in Windows 2000/XP?
Syslog can email you alerts, centralize reporting, etc. etc. So why ask your access point to send you mail, just have the syslog server running "logwatch" and send you pages or whatever when you see bad shit goin' down.
no, it was empirial. And everyone was encouraged to become civil servants, merchants were frowned upon, and resources were aggresively micromanaged by local magnates. Expressing excessive emotion, or religious conviction beyond societial norms was consider immoral.
Huh, sounds pretty socialist to me. It was only AFTER they tried to Westernize in the late 19th and early 20th centuries, and FAILED, that they reverted to old ways under the guise of a (new) Communist revolution.
It's not like OpenGL didn't work well on Windows even when they begrudgingly permitted it! I remember a time when it was that or nothing because Direct3d lacked a lot features (and could become unstable).
It's like they had this DirectX thing to give them HAL in Chicago, so they decided it would be better to bundle an OpenGL competitor into that infrastructure than adapting it to use it.
I sometimes think it wasn' been malicious, just a dumb, hamfisted idea born straight out of a gungho project manager based on stuff pulled from the OpenGL meetings.
China has always been crowded, and always been centrally administered/socialist, since 1500BCE and earlier.
It's the only way they have managed to survive. Eventually as they continue industrializing (and reduce the population vs. land area, esp. in rural zones) conditions will improve.
We want China to keep striving at "pointless" pursuits. It's a good sign, overall; regardless of the unpalatable practices (and that's your opinion) that many suffer under.
Does the fact that he signs with his supposed credentials seem in any way suspicious to you?
Besides, I can't think of one Indian person I know in college who reads slashdot, mostly because people here curse them out non-stop, blaming them for lost jobs.
Try delivering my post in a straight, candid monotone, without giggling.
Pure gold, chum.
I just love to harass those people who give in to first posts, reply to "nigger/goatse/editors-related" crapfloods, etc. and I'll waste my karma doing it.
of a CD player at 44.1 kHz, sent syncronously over SPDIF using it's own clock, to a receiver playing at 44.05 kHz (it's clock is LITERALLY slower).
What would happen?
Nothing audible (except a slight time shift every so often, I'll explain).
The receiver probably has a buffer about 128-bytes in length. As SPDIF transitions CLK+ high, the receiver reads DATA and inserts it into a sample-width receiver buffer. It left shifts it, and waits for CLK to transition. It does this as fast as possible.
It never misses a bit the CD player can send, because it's always waiting for CLK (and we assume DATA is not spread so much that you cannot reliably read it 1uS beyond the clock transition, that would be a transmission quality so horrible to be unthinkable)
When it reads and shifts 16 times, the async receiver interrupts a microcontroller sitting on the RAM buffer and informs it a sample is ready. Meanwhile it opens a latch behind the buffer to permanently copy it another buffer. The microcontroller wakes up and reads this value into the FIFO from the back buffer. If the FIFO is full, the microcontroller instead ignores the new value.
Finally, the DAC in the receiver, is at the same time, requesting the next value in the FIFO to be copied into a latch while it generates voltage for the previous value to be amplified. If the FIFO cannot give another value, it leaves the old value in the latch.
So the DAC is ALWAYS setting a voltage right on time, everytime. But sometimes the microcontroller presents it a sample ahead of time if it skipped one because data comes in too fast. Sometimes it doesn't change the last value when data comes in to slow.
But never is there any jitter. The only jitter is in how accurately and regularly the DAC activates it's voltage output. The microcontroller uses a buffer to meet to demands of both sides without exposing an underlying clock.
In our case, the FIFO would constantly be full, and sometimes reject a data sent in via the CD player because the DAC in the receiver does not remove them fast enough.
If the clocks were about the same , but experienced jitter, the depth of the FIFO would probably vary as the time bases diverged (and the in vs. out flow varied), but you would always experience jitter from the DAC's clock only in the analog output.
If you put in a pure sine wave digitally through the input, you could precisely measure the output DAC jitter with a spectrum analyzer, regardless of how the digital sine wave is produced (provided that the samples are mathematically equally spaced in the sine function with respect to their order... you get the idea)
But ONLY at the very last stage. Hence, the final clock (which is always internal to your sound card or receiver, integrated digital amplifier or what have you) is the ultimate determination in preventing spread spectrum.
You have no AD stage to worry about. The AD part is done at the studio and cannot be fixed, if jitter was present. However, if you keep each bit in line and stay digital the whole way until the end, as long as the DA has no appreciable jitter, then the jitter error in the output analog signal will be not much worse than what was already present when it was mastered. At least you can minimize the DA jitter and get as close to the master as possible (assuming the master's timebase was 100% accurate). The easiest way? Do the conversion once with the most accurate clock possible.
That website mostly concerns itself with BOTH the AD and DA stages. The AD stage is quite complicated to resolve, so it may have confused you. Playback of digital data requires no such complex stage.
Everybody, and I mean everybody, sends the data asyncronously and de-serializes into UART buffers at some multiple of the sample width (16-bit FIFOs for RS-435, 128-byte (IIRC) FIFOs on the Envy24 SPDIF controllers, etc. etc.) which is then transfered out via DMA in parallel over standard system buses for processing like an other data (LOSSLESSLY, obviously). It gets re-serialized by a sound card eventually when fed into the DAC, and the quality of the DAC's clock input is the only part that determines jitter. The serialization/buffering/deserialization (which is synomous with "data retiming") step at each protocol boundary eliminates any possibility of and bit loss or syncronozation loss between interfaces. I guarantee that every interface in existance does this in the UART because no other design is reliable.
If there was any foul ups earlier on in the chain, you'd lose at least whole place in the significant bit of some value, which would translate into a loud, audible click if it pulled in a high bit into a MSB's missing place accidentally. But most standards use start/stop framing, so you'd probably get a withheld sample frame, which would either be interpolated over or dropped (I/O error, handled in various ways depending on hardware or OS, if any).
The iPod benefits from the excellent WM8371 audio codec with built-in clock generator (at 44, 48, and 96 kHz). The stereophile article details it's marvelous clock stability.
It is also a easily replaced/interchangable component. (May I suggest a sound card based on the CS436X chipset? They are top notch in the jitter, SNR, and common mode rejection department)
Let me restate, your website is correct! It does matter. BUt they don't explain well enough that there's only one point that it matters, and that's at the very END. As long as you don't use any other clock besides the high-quality one at the end, and you don't lose any data along the way, you will hear no artifacts, distortions, or anything (whether audible or not).
Trust me, you cannot "hear the difference" if the processing stages in the digital domain are working (either they are, 100%, or aren't, with loud pops and stutters... binary transmitted data doesn't "degrade" into nearby values in it's native form, it causes serious errors)
I can draw you a series of diagrams explaining the whole if you so desire.
Because it's actually based on Server 2003. Server 2003 dropped 16-bit support, and doesn't include Windows Media or the Luna interface (by default, but you can get those parts back).
TTL, RS-485, SPDIF, DVI-D, IEEE1394, USB-audio, etc. logic is low impedence drive, high impedence load. The electronics DO NOT CARE. If the cable is sub-par (picking up too much noise, too high impedence over a long run), you'll get voltage fluctuations with translate into bit errors, which transforms into missed frames, which translates into:
1) static 2) blocking artifacts in video, or stutters in sound 3) dropped signal completely if it loses sync (provided the protocol standard requires it)
Overheating. OVERHEATING WHAT?>????!! A UART?
Jesus fucking christ.
Out of phase sound my ass. Explain to me how a serialized PCM signal gets "out of phase". Does the cable magically declock, FFT the sound into bands, then reclock and transmit coefficients from one band out of step with the others?
It seems that YOU are the one to whom things don't make sense, and you have built flawed analogies to try to cope with your inability to comprehend the most slightly complex thing. Effortless, stress, WHAT, ARE THERE OVERWORKED GARDEN GNOMES IN YOUR EQUIPMENT? Then you have the nerve to tell me that I'm wrong.
YOU HAVE NO FUCKING CLUE HOW ANY OF IT WORKS DO YOU?
Nikki, it was not my intention to do this in front of you. For that I'm sorry. But you can take my word for it, your mother had it coming. When you grow up, if you still feel raw about it, I'll be waiting.
Thanks for writing a reply that I was to tired to... do...
*sigh*
Just wanted to say I love balanced vs. unbalanced cables and I was wondering if you had any experience with using CAT5 as a cheap substitute.
I've been hearing great things about it from the sidelines.
Imagine, 4 channels using all 4 pairs! Whee. And a really neat connector that doesn't pull loose when you move around. And you can bend them. Zow!
It seems like a great idea considering the cables are rated to reliably transfer modulated data at 350MHz and up for 100 meters, and that's the cheap, $1@foot stuff.
Slashdot Mirror
With the pentium pro, K6, etc.
No operation is directly executed anymore, it's all interpreted.
I bought two computers for the price of your one computer, and I can invite a friend to play Unreal Tournament with me.
Ahhh, yes, LAN party.
What were you talking about?
Everyone has now given into the fact that you need more complexity to get higher performance per clock.
Evidence of this: The multiple-logical-core (see Aurora, Intel HT, EPIC, Power5) trend is the next step in complexity beyond pipelining and predictive execution/caching.
Do you hear anyone referring to AMD64 as "K8"? I hear AMD64, x86_64, Opteron, Athlon64, but never K8 (maybe once or twice, to relate how similar the FX, Athlon64 and Opteron are)
So we'll call it K9 in the same way we call PentiumPro/II/III all i686. And no one will get the dog jokes, except us, and maybe 4 readers and 1 of the creators of Penny Arcade.
How sad.
just... no.
How many of these are burning 600 watt power supplies just to power all the glo- wire and eye candy?
None. A hard drive will require more power than a case with the monetary equivalent ($100-$200) worth of ultra-brite LEDs.
And I will wager that less than 10% of current computer owners in the US are even wont to open their cases, and a much smaller number will actually want to spend the money on lights and racing stripes.
His comment did not warrant a response as it was vacant of anything resembling an argument or relevant observation.
By throwing in the word "fag", he gets the attention of trolls who would love to start a flamewar.
Is there room on Slashdot for trolls who troll the trolls? Metatrolling?
Also, it is not also polite to not judge a person by the clothes that he wears? Hygiene is a necessity, not an aesthetic, hence it is a poor analogy you make.
This post is going nowhere. I think I'll just cut...
by the biggest dicklicker on Slashdot, Sir Sucks-a-lot.
You copied the PUBLISHERS' blurb. No wonder it was positively glowing.
I recommend not buying the book because it's as full on "insight" as this loser's posts. It's only 6 chapters long, and if it was really going to convicne me it'd have to be a lot longer and features twice as many references. Just pointing things out that go with the author's pet theory does not a good argument make.
Is the Canopy group the ugly face of some kind of parasite which feeds on the Internet and technology? Everything they touch smells like death and decay.
I wish Trolltech would throw them off so I can believe there's not some kind of sinister connection beneath the surface.
Some of them support syslog, which is not really much help to Windows people and a bit arcane for a lot of Linux people.
Gee-whiz, I mean syslog isn't like this CORE service of every modern Unix: why not learn how to use it? Arcane. Hardly. Essential is more like if you give a damn about your system.
I mean, do you not use the Event Viewer in Windows 2000/XP?
Syslog can email you alerts, centralize reporting, etc. etc. So why ask your access point to send you mail, just have the syslog server running "logwatch" and send you pages or whatever when you see bad shit goin' down.
no, it was empirial. And everyone was encouraged to become civil servants, merchants were frowned upon, and resources were aggresively micromanaged by local magnates. Expressing excessive emotion, or religious conviction beyond societial norms was consider immoral.
Huh, sounds pretty socialist to me. It was only AFTER they tried to Westernize in the late 19th and early 20th centuries, and FAILED, that they reverted to old ways under the guise of a (new) Communist revolution.
It's not like OpenGL didn't work well on Windows even when they begrudgingly permitted it! I remember a time when it was that or nothing because Direct3d lacked a lot features (and could become unstable).
It's like they had this DirectX thing to give them HAL in Chicago, so they decided it would be better to bundle an OpenGL competitor into that infrastructure than adapting it to use it.
I sometimes think it wasn' been malicious, just a dumb, hamfisted idea born straight out of a gungho project manager based on stuff pulled from the OpenGL meetings.
Man that was GREAT to program for, and the DRIVERs and protocol stacks were SUPERB.
:-)
Oh wait, no it wasn't! I sense a pattern here.
China has always been crowded, and always been centrally administered/socialist, since 1500BCE and earlier.
It's the only way they have managed to survive. Eventually as they continue industrializing (and reduce the population vs. land area, esp. in rural zones) conditions will improve.
We want China to keep striving at "pointless" pursuits. It's a good sign, overall; regardless of the unpalatable practices (and that's your opinion) that many suffer under.
You replied to a known troll.
Does the fact that he signs with his supposed credentials seem in any way suspicious to you?
Besides, I can't think of one Indian person I know in college who reads slashdot, mostly because people here curse them out non-stop, blaming them for lost jobs.
"pant, pant... whew... finally... acheived... gay"
Try delivering my post in a straight, candid monotone, without giggling.
Pure gold, chum.
I just love to harass those people who give in to first posts, reply to "nigger/goatse/editors-related" crapfloods, etc. and I'll waste my karma doing it.
finally... what? Gay?
So you're finally gay. Congratulations. You've joined the FP club (faggot posters).
of a CD player at 44.1 kHz, sent syncronously over SPDIF using it's own clock, to a receiver playing at 44.05 kHz (it's clock is LITERALLY slower).
What would happen?
Nothing audible (except a slight time shift every so often, I'll explain).
The receiver probably has a buffer about 128-bytes in length. As SPDIF transitions CLK+ high, the receiver reads DATA and inserts it into a sample-width receiver buffer. It left shifts it, and waits for CLK to transition. It does this as fast as possible.
It never misses a bit the CD player can send, because it's always waiting for CLK (and we assume DATA is not spread so much that you cannot reliably read it 1uS beyond the clock transition, that would be a transmission quality so horrible to be unthinkable)
When it reads and shifts 16 times, the async receiver interrupts a microcontroller sitting on the RAM buffer and informs it a sample is ready. Meanwhile it opens a latch behind the buffer to permanently copy it another buffer. The microcontroller wakes up and reads this value into the FIFO from the back buffer. If the FIFO is full, the microcontroller instead ignores the new value.
Finally, the DAC in the receiver, is at the same time, requesting the next value in the FIFO to be copied into a latch while it generates voltage for the previous value to be amplified. If the FIFO cannot give another value, it leaves the old value in the latch.
So the DAC is ALWAYS setting a voltage right on time, everytime. But sometimes the microcontroller presents it a sample ahead of time if it skipped one because data comes in too fast. Sometimes it doesn't change the last value when data comes in to slow.
But never is there any jitter. The only jitter is in how accurately and regularly the DAC activates it's voltage output. The microcontroller uses a buffer to meet to demands of both sides without exposing an underlying clock.
In our case, the FIFO would constantly be full, and sometimes reject a data sent in via the CD player because the DAC in the receiver does not remove them fast enough.
If the clocks were about the same , but experienced jitter, the depth of the FIFO would probably vary as the time bases diverged (and the in vs. out flow varied), but you would always experience jitter from the DAC's clock only in the analog output.
If you put in a pure sine wave digitally through the input, you could precisely measure the output DAC jitter with a spectrum analyzer, regardless of how the digital sine wave is produced (provided that the samples are mathematically equally spaced in the sine function with respect to their order... you get the idea)
But ONLY at the very last stage. Hence, the final clock (which is always internal to your sound card or receiver, integrated digital amplifier or what have you) is the ultimate determination in preventing spread spectrum.
You have no AD stage to worry about. The AD part is done at the studio and cannot be fixed, if jitter was present.
However, if you keep each bit in line and stay digital the whole way until the end, as long as the DA has no appreciable jitter, then the jitter error in the output analog signal will be not much worse than what was already present when it was mastered. At least you can minimize the DA jitter and get as close to the master as possible (assuming the master's timebase was 100% accurate). The easiest way? Do the conversion once with the most accurate clock possible.
That website mostly concerns itself with BOTH the AD and DA stages. The AD stage is quite complicated to resolve, so it may have confused you. Playback of digital data requires no such complex stage.
Everybody, and I mean everybody, sends the data asyncronously and de-serializes into UART buffers at some multiple of the sample width (16-bit FIFOs for RS-435, 128-byte (IIRC) FIFOs on the Envy24 SPDIF controllers, etc. etc.) which is then transfered out via DMA in parallel over standard system buses for processing like an other data (LOSSLESSLY, obviously).
It gets re-serialized by a sound card eventually when fed into the DAC, and the quality of the DAC's clock input is the only part that determines jitter.
The serialization/buffering/deserialization (which is synomous with "data retiming") step at each protocol boundary eliminates any possibility of and bit loss or syncronozation loss between interfaces. I guarantee that every interface in existance does this in the UART because no other design is reliable.
If there was any foul ups earlier on in the chain, you'd lose at least whole place in the significant bit of some value, which would translate into a loud, audible click if it pulled in a high bit into a MSB's missing place accidentally. But most standards use start/stop framing, so you'd probably get a withheld sample frame, which would either be interpolated over or dropped (I/O error, handled in various ways depending on hardware or OS, if any).
The iPod benefits from the excellent WM8371 audio codec with built-in clock generator (at 44, 48, and 96 kHz). The stereophile article details it's marvelous clock stability.
It is also a easily replaced/interchangable component. (May I suggest a sound card based on the CS436X chipset? They are top notch in the jitter, SNR, and common mode rejection department)
Let me restate, your website is correct! It does matter. BUt they don't explain well enough that there's only one point that it matters, and that's at the very END. As long as you don't use any other clock besides the high-quality one at the end, and you don't lose any data along the way, you will hear no artifacts, distortions, or anything (whether audible or not).
Trust me, you cannot "hear the difference" if the processing stages in the digital domain are working (either they are, 100%, or aren't, with loud pops and stutters... binary transmitted data doesn't "degrade" into nearby values in it's native form, it causes serious errors)
I can draw you a series of diagrams explaining the whole if you so desire.
Because it's actually based on Server 2003. Server 2003 dropped 16-bit support, and doesn't include Windows Media or the Luna interface (by default, but you can get those parts back).
That's probably what they're talking about.
that can suffer from jitter.
You honestly think the DAC in your receiver is using the same clock that is used to syncronously transfer data across the SPDIF channel?
Not unless you have an SMTP-E timebase rackmount unit or some shit.
Fuck man, almost every data transfer spec is asyncronous anyway, so it's reg'd up and buffer at least a few times during transmission.
I know exactly what jitter is, and I know exactly that this guy doesn't know what he's talking about BECAUSE IT DOES NOT APPLY.
Does your serial port at 115K suffer from jitter? HUH? Jesus christ people.
What the fuck are you talking about.
TTL, RS-485, SPDIF, DVI-D, IEEE1394, USB-audio, etc. logic is low impedence drive, high impedence load. The electronics DO NOT CARE. If the cable is sub-par (picking up too much noise, too high impedence over a long run), you'll get voltage fluctuations with translate into bit errors, which transforms into missed frames, which translates into:
1) static
2) blocking artifacts in video, or stutters in sound
3) dropped signal completely if it loses sync (provided the protocol standard requires it)
Overheating. OVERHEATING WHAT?>????!! A UART?
Jesus fucking christ.
Out of phase sound my ass. Explain to me how a serialized PCM signal gets "out of phase". Does the cable magically declock, FFT the sound into bands, then reclock and transmit coefficients from one band out of step with the others?
It seems that YOU are the one to whom things don't make sense, and you have built flawed analogies to try to cope with your inability to comprehend the most slightly complex thing. Effortless, stress, WHAT, ARE THERE OVERWORKED GARDEN GNOMES IN YOUR EQUIPMENT? Then you have the nerve to tell me that I'm wrong.
YOU HAVE NO FUCKING CLUE HOW ANY OF IT WORKS DO YOU?
Me Chinese
Me pray joke
Me put rocket in you ass. Opppsies!
hahahahhahahaa funeee
Nikki, it was not my intention to do this in front of you. For that I'm sorry. But you can take my word for it, your mother had it coming. When you grow up, if you still feel raw about it, I'll be waiting.
Thanks for writing a reply that I was to tired to... do ...
*sigh*
Just wanted to say I love balanced vs. unbalanced cables and I was wondering if you had any experience with using CAT5 as a cheap substitute.
I've been hearing great things about it from the sidelines.
Imagine, 4 channels using all 4 pairs! Whee.
And a really neat connector that doesn't pull loose when you move around. And you can bend them. Zow!
It seems like a great idea considering the cables are rated to reliably transfer modulated data at 350MHz and up for 100 meters, and that's the cheap, $1@foot stuff.
Eh... just rambling.