Spoken like a first-year undergraduate! Search the literature for microphonic ceramic. The microphonic effect of multilayer chip capacitors is very well known.
I don't think it's patented. Almost any professional digital equipment can be slaved to what's called the "house clock". I think it is just too expensive (at least a dollar added to the bill of materials) to implement in consumer gear, and nobody (only those with their own external DACs or house clocks) would use it.
Schottky diodes do not "ring". No single component can ring, you need a circuit, with more than one component, before you get ringing. A Schottky barrier diode has no stored charge, and therefore does not snap off like a normal juntion diode. FREDs and other controlled-recovery diodes do have stored charge, but their recovery condition is characterized and guaranteed by the manufacturer. Many FREDs will cause terrible ringing. You have to design around their recovery characteristic.
Basically I wanted to point out that I think you are misleading the audience. Schottky diodes are the least susceptible to ringing. Fast recovery are probably the worst, regular 4004 are better than fast, and controlled (aka soft) recovery are better still, but none as good as Schottky for your standard 60Hz AC/DC supply implementation.
Wrong. The clock is in the player, transmitted over S/PDIF, and recovered by the DAC. That transmission and recovery step is fraught with peril, and it is guaranteed by the design of the S/PDIF signalling to have data-correlated time domain distortion. The only way to avoid this problem is to put the master clock in the DAC (as you say) and slave the player's clock to it, so that the two run in synchronized clock domains. But only DIYers and professionals have such equipment. To the best of my knowledge no manufacturer has marketed a consumer DVD player with a clock-sync input.
Do you feel that crystal oscillators are immune to vibration? That would seem to contradict the basic principle of quartz crystal operation (the piezoelectric effect). Indeed, the cheap low-grade ceramic bypass capacitors, of which there are probably dozens or hundreds in the average DVD player, demonstrate substantial piezoelectric behavior. You can tap a Y5V ceramic capacitor with the tip of a pencil and see the effects on your oscilloscope.
These are the sorts of things that get you from 16-bit performance, which is pretty easy, to 24-bit performance, which is dreadfully hard. Even air currents blowing across the leads of your opamp will cost you an LSB or two.
Certainly you aren't implying that improving the power supply is useless, right? Your average consumer equipment comes with a power supply that is regulated only at very low frequencies, whereas the electronics in such a device need clean operation often up to 1MHz or more to acheive their nominal goals (24-bit, 192KHz reproduction, for example).
The $50 capacitors are contiuously-wound film-and-foil polypropylene capacitors. They are very expensive not because their margins are so high, but simply because of the sheer amount of dielectric used. You do not need to go to these lengths to get good sound: a low-priced compact metallized polypropelene can do the trick as well, and you can get these from Digi-key and Mouser. The point is to replace to ridiculous, totally unsuitable electrolytic coupling capacitors the manufacturer chose.
I've never heard of RCA jack mania in the DIY world. All the DIY equipment I've built, and all the equipment I've seen at DIY meetings have had XLR or BNC jacks.
You do see to be assuming that the DIY hackers in the IEEE article have never met a scope. I assure you that a Tek 465 is the first piece of equipment your basic DIY audio workshop buys. People who modify DVD players are well aware of the power supply issues present in these high-speed mixed analog and digital devices. While there are a lot of crackpots in the audio world, there are also many proven designs, and plenty of knowledge floating around.
You have obviously never encountered the "Fast WACK", the fsck-equivalent for NetApp that their sales organization swears does not exist, and their support organization has never heard of.
NetApp are a bunch of chronic liars, and no amount of support can cover up that problem.
That's because Dell isn't a service organization, they are a supply chain management firm. Once the machine leaves the door, they don't want to hear about it even again. If you are an IBM or HP customer you can easily contrast the support you get from IBM services division with the support you get from Dell. Dell just doesn't want to help you. IBM will be quite happy to help you; that's how they make all their money.
Well, that's because local control is best, and the more local the better. The USA doesn't pay a lot of attention to grandstanding gasbags from Outer Bloaghmistan. We in California don't want to have to obey the whims of some jerks from Kansas. In the same way, San Franciscans don't particularly feel like having to go along with a lot of homophobes from... well I don't know where really, Turlock or something, probably.
I think the state proposition system has seen more agistation on the part of conservative and reactionary groups than liberals and progressives. Prop 13 was a full-on tax revolt, of course. But a ton of propositions have been brought up through largely conservative systems, like organized religions, or chambers of commerce. I promise you there will be plenty of oddball offerings from all parts of the spectrum on the next state ballot.
The pipeline is genius, but you'd still like to have concurrency in a single pipe stage. The best example is GNU sort, which does I/O... sort... I/O... sort... I/O... sort, alternating quite inefficiently until a final merge. If GNU sort could take advantage of multiple CPUs it would run quite a bit faster, and sorting by divide-and-conquer is one of the most easily-parallelized processes.
I'm not too excited about the multi-threading aspects of this new Sun processor, but I'm definitely happy about 8 cores, 3MB cache, and 4-channel memory interface. I think it will be a parallel-sorting monster.
In the very rare case that I need to use MS Office, I still use the copy of Office Professional I got when I bought a 60MHz Pentium from Gateway 2000, 11 years ago. It fairly screams. As far as I can tell, they haven't added any useful features to either Excel or Word since.
I'm not talking about the protocols themselves being broken, I'm talking about the implementations. If MacOS or 3rd-party code assumes that network order and host order are equivalent, those implementations will be broken. Maybe you are a genius but I've personally written some code that didn't port between machines because of subtle byteorder problems.
Basically I think your second paragraph applies to protocols, and for the same reason. Anything that assumes ifdef macos is equivalent to ifdef BE is broken.
I would wager that Apple has relatively little work to do porting AltiVec implementations to SSE. AltiVec for Core and Quartz is irrelevant because all future machines will support them in the GPU. So you don't need to port any of that junk over to SSE. That leaves a paltry handful of algorithms, probably in codecs and whatnot.
That only covers the OS. Fixing Shake and Logic and Final Cut will be much more work.
I'm positive there are sticking points other than AltiVec. What about byte order? The last Great Architecture Switch was easier because 68040 and PPC were both big-endian. Pentium is little-endian. On-disk formats and wire protocols could break.
The Cell is an in-order CPU. Where do people get the idea that it will be of any use for branchy general-purpose workloads? It's going to absolutely smoke for games, but I don't think Matlab is going to get a big boost.
Nearly every store on the web keeps your credit card number on file in plain text. Most people just assume their local database is private, which is obviously incorrect.
People in Utah live under a de facto theocracy. It's almost reasonable for Utes to fear a government internet service, especially if it drives private alternatives out of business.
I used to maintain the binary distribution of Apache+mod_perl for Windows. It was a right pain in the ass, and core-dumped all the time, and was fully serialized. But I understand it's much better now that Apache 2 is out there.
Maybe Slashdot can finally stop running stories about this bad television show. The title "Star Trek" does not automatically impart artistic quality. It's a bad, boring, cheesy, trite, poorly-written, poorly-acted, poorly-conceived piece of crap. That's why they cancelled it! How about some Stuff That Matters for once?
According to Google, 15% of recent Slashdot stories have been about this eighth-rate television show. It's really pathetic.
Thanks for the info on the key implementation. What's the encryption like? It would seem that anything serious (like AES) would ruin the battery life and/or be more than the iPod's tiny brain can deal with.
By the way, there's actually nothing preventing you from eavesdropping the iTunes network communications, SSL or otherwise. I know on MacOS iTunes proactively avoids debugging (by installing a trap to abort on ptrace) but iTunes for Win32 can be hooked using the microsoft research package which I think is called "detours." You can replace the decryption in the SSL routines to blurt the plaintext out to a file.
Just another example of why the local machine cannot be trusted (using the DRM-influenced form of the word "trust"). I'm sure we'll all have DRM CPUs soon.
The hack being "cp", but I do see your point. Also iTunes itself won't play protected AAC files taken from an iPod (via any means, hacking or otherwise), and as far as I know there's no common Windows or MacOS software that will. Only certain open source utilities will play protected AAC files regardless of protected status, and besides that there are the programs that remove the protection altogether. Which is probably also "hacking" in certain circles.
Real's reverse engineering consists of putting their own DRM format onto the iPod, not cracking the iPod's native DRM format. Real also had to whip up their own code to work with the iPod's song database, but there are lots of open projects doing that.
Here's what Apple's FairPlay DRM means for users: any iPod can play any iTMS-purchased AAC, which implies there is a master key for decoding the FairPlay file. Apple's software respects the flags in the FairPlay file which indicate what computers are authorized to play the file. Other software may ignore the flags and decode the file anyway. You do need certain decryption keys to do this (see JHymn, PlayFair).
So the iPod will play any AAC file (protected or unprotected), any regular MP3 file, and any regular uncompressed PCM file. The only reason Real needs to jump through hoops is because they want their stupid DRM format to work.
Slashdot Mirror
Spoken like a first-year undergraduate! Search the literature for microphonic ceramic. The microphonic effect of multilayer chip capacitors is very well known.
I don't think it's patented. Almost any professional digital equipment can be slaved to what's called the "house clock". I think it is just too expensive (at least a dollar added to the bill of materials) to implement in consumer gear, and nobody (only those with their own external DACs or house clocks) would use it.
Basically I wanted to point out that I think you are misleading the audience. Schottky diodes are the least susceptible to ringing. Fast recovery are probably the worst, regular 4004 are better than fast, and controlled (aka soft) recovery are better still, but none as good as Schottky for your standard 60Hz AC/DC supply implementation.
Wrong. The clock is in the player, transmitted over S/PDIF, and recovered by the DAC. That transmission and recovery step is fraught with peril, and it is guaranteed by the design of the S/PDIF signalling to have data-correlated time domain distortion. The only way to avoid this problem is to put the master clock in the DAC (as you say) and slave the player's clock to it, so that the two run in synchronized clock domains. But only DIYers and professionals have such equipment. To the best of my knowledge no manufacturer has marketed a consumer DVD player with a clock-sync input.
These are the sorts of things that get you from 16-bit performance, which is pretty easy, to 24-bit performance, which is dreadfully hard. Even air currents blowing across the leads of your opamp will cost you an LSB or two.
The $50 capacitors are contiuously-wound film-and-foil polypropylene capacitors. They are very expensive not because their margins are so high, but simply because of the sheer amount of dielectric used. You do not need to go to these lengths to get good sound: a low-priced compact metallized polypropelene can do the trick as well, and you can get these from Digi-key and Mouser. The point is to replace to ridiculous, totally unsuitable electrolytic coupling capacitors the manufacturer chose.
I've never heard of RCA jack mania in the DIY world. All the DIY equipment I've built, and all the equipment I've seen at DIY meetings have had XLR or BNC jacks.
You do see to be assuming that the DIY hackers in the IEEE article have never met a scope. I assure you that a Tek 465 is the first piece of equipment your basic DIY audio workshop buys. People who modify DVD players are well aware of the power supply issues present in these high-speed mixed analog and digital devices. While there are a lot of crackpots in the audio world, there are also many proven designs, and plenty of knowledge floating around.
NetApp are a bunch of chronic liars, and no amount of support can cover up that problem.
That's because Dell isn't a service organization, they are a supply chain management firm. Once the machine leaves the door, they don't want to hear about it even again. If you are an IBM or HP customer you can easily contrast the support you get from IBM services division with the support you get from Dell. Dell just doesn't want to help you. IBM will be quite happy to help you; that's how they make all their money.
I think the state proposition system has seen more agistation on the part of conservative and reactionary groups than liberals and progressives. Prop 13 was a full-on tax revolt, of course. But a ton of propositions have been brought up through largely conservative systems, like organized religions, or chambers of commerce. I promise you there will be plenty of oddball offerings from all parts of the spectrum on the next state ballot.
The pipeline is genius, but you'd still like to have concurrency in a single pipe stage. The best example is GNU sort, which does I/O ... sort ... I/O ... sort ... I/O ... sort, alternating quite inefficiently until a final merge. If GNU sort could take advantage of multiple CPUs it would run quite a bit faster, and sorting by divide-and-conquer is one of the most easily-parallelized processes.
I'm not too excited about the multi-threading aspects of this new Sun processor, but I'm definitely happy about 8 cores, 3MB cache, and 4-channel memory interface. I think it will be a parallel-sorting monster.
In the very rare case that I need to use MS Office, I still use the copy of Office Professional I got when I bought a 60MHz Pentium from Gateway 2000, 11 years ago. It fairly screams. As far as I can tell, they haven't added any useful features to either Excel or Word since.
I'm not talking about the protocols themselves being broken, I'm talking about the implementations. If MacOS or 3rd-party code assumes that network order and host order are equivalent, those implementations will be broken. Maybe you are a genius but I've personally written some code that didn't port between machines because of subtle byteorder problems. Basically I think your second paragraph applies to protocols, and for the same reason. Anything that assumes ifdef macos is equivalent to ifdef BE is broken.
I would wager that Apple has relatively little work to do porting AltiVec implementations to SSE. AltiVec for Core and Quartz is irrelevant because all future machines will support them in the GPU. So you don't need to port any of that junk over to SSE. That leaves a paltry handful of algorithms, probably in codecs and whatnot.
That only covers the OS. Fixing Shake and Logic and Final Cut will be much more work.
I'm positive there are sticking points other than AltiVec. What about byte order? The last Great Architecture Switch was easier because 68040 and PPC were both big-endian. Pentium is little-endian. On-disk formats and wire protocols could break.
Linux (Debian, Yellow Dog, others) already runs on the Mac. Switching CPUs makes Linux-on-Mac neither more nor less possible.
The Cell is an in-order CPU. Where do people get the idea that it will be of any use for branchy general-purpose workloads? It's going to absolutely smoke for games, but I don't think Matlab is going to get a big boost.
Nearly every store on the web keeps your credit card number on file in plain text. Most people just assume their local database is private, which is obviously incorrect.
Salt, anyone?
People in Utah live under a de facto theocracy. It's almost reasonable for Utes to fear a government internet service, especially if it drives private alternatives out of business.
I used to maintain the binary distribution of Apache+mod_perl for Windows. It was a right pain in the ass, and core-dumped all the time, and was fully serialized. But I understand it's much better now that Apache 2 is out there.
It's cheap, low-power, and quiet. Other than those, no reason.
According to Google, 15% of recent Slashdot stories have been about this eighth-rate television show. It's really pathetic.
By the way, there's actually nothing preventing you from eavesdropping the iTunes network communications, SSL or otherwise. I know on MacOS iTunes proactively avoids debugging (by installing a trap to abort on ptrace) but iTunes for Win32 can be hooked using the microsoft research package which I think is called "detours." You can replace the decryption in the SSL routines to blurt the plaintext out to a file.
Just another example of why the local machine cannot be trusted (using the DRM-influenced form of the word "trust"). I'm sure we'll all have DRM CPUs soon.
The hack being "cp", but I do see your point. Also iTunes itself won't play protected AAC files taken from an iPod (via any means, hacking or otherwise), and as far as I know there's no common Windows or MacOS software that will. Only certain open source utilities will play protected AAC files regardless of protected status, and besides that there are the programs that remove the protection altogether. Which is probably also "hacking" in certain circles.
Here's what Apple's FairPlay DRM means for users: any iPod can play any iTMS-purchased AAC, which implies there is a master key for decoding the FairPlay file. Apple's software respects the flags in the FairPlay file which indicate what computers are authorized to play the file. Other software may ignore the flags and decode the file anyway. You do need certain decryption keys to do this (see JHymn, PlayFair).
So the iPod will play any AAC file (protected or unprotected), any regular MP3 file, and any regular uncompressed PCM file. The only reason Real needs to jump through hoops is because they want their stupid DRM format to work.