In my estimation, every sound card (onboard or what not) is about on par with very good quality this way, since the onboard DAC isn't sending amplified trace noise out of the board.
You're right about analog noise, but sadly there are too many soundcards with digital output that support only one output frequency (i.e. either 44.1kHz or 48kHz). This makes it much easier to mix analog and digital sources to one output, but introduces artifacts due to more or less shoddy resampling - and some even show artifacts when you feed them at their preset output frequency because they resample even that.
For me that would be a 10 minute (one way) ride out in the cold and/or rain (or whatever) only to find that the movie I wanted isn't available because either all DVDs are already rented out or they have stopped carrying that one because it's too old.
If you are right-handed, you would hold a chisel in your left and the hammer that usually goes with it in your right. Personally I think I would have difficulties hitting the chisel if I were operating a hammer with my left hand. One could argue that this makes writing from right to left easier, because you have to lift the hammer anyway, and to get the chisel out of the way, you only have to lift it a tiny bit and turn your hand a bit counterclockwise.
With a product that sells worldwide, you really have to ask what kind of TV tuner you expect to be put in it. A good old analog one that would be obsolete in just a few years? Or ATSC? Maybe a cable tuner, now that the cable card would allow you to use non-proprieatary boxes. Or DVB for Europe, but which one, terrestial, satellite or cable? Or maybe an analog HDTV tuner for Japan?
Personally, I'd think that some hooks, holes, clamps or whatever to strap a small 3rd party tuner like the eyeTV on the back would be the way to go.
And IBM claimed they'd intended to use paint that washes away, much like the chalk bikesagainstbush uses, but they somehow ended up using permanent paint. They ended up paying a US$100000 fine. I hope the bikesagainstbush guy has tested his paint, so that no such unpleasant surprises can happen to him.
the human eye cannot distinguish between that many shades (particularly in the blue region)
While it may seem counterintuitive, the human eye is much better at discriminating between shades of blue than between red or green (where it is worst by far). There's a nice graph showing the MacAdam ellipses that represent the amount of variation in chromaticity where no difference can be percieved in this paper. This is obviously different from the responsiveness to brightness.
16 bit color representaion usually has the 6 bits for green.
For most people, 8 bit per RGB component on an linear scale, as used in almost all computers, is not enough - you can still see some banding. A logarithmic scale or 10 bit color can fix this.
170db with a cell phone? Hardly, because it would probably just fall apart at that level, but the equivalent of 140db measured from 1m away? Maybe, since the distance is probably in the range of 5 mm, and thus just 1/200th of the distance that's usually used to take those measurments. Additionally, due to the proximity, a large part of the acoustic energy emitted by the phone enters your ear. Note that at 140db the extrapolation you attempted above fails, because at that level immediate damage may occur.
I think that the loud noise it plays is not actually the battery warning, but it's the user-defined melody the phone plays when it has finally given up and shuts down.
Re:KDE and Knome infect X ?
on
The Power of X
·
· Score: 2, Interesting
I fear that in the long term windows manager features will included into the X server.
That's something I'd actually like to happen - the way it was in the NEWS system (just better). In my opinion, it would actually be beneficial to replace the window manager with a script running inside the server, or even to allow application to upload scripts to the server that handle their Menus so that there are no unnecessary delays going back and forth between the X-Server and a remote client for stuff as trivial as moving a window or opening a menu.
Well, as I said, they don't just increase the data density along the tracks, they also make the tracks less wide and pack them closer together. At constant RPM, you will usually only see an increase in speed around the square root of the increase in density for this exact reason.
If speed scaling was linear in the capacity, harddisks today would have to be in the vincinity of 14 Gigabytes per second, since back in 1990 my 40MB HD had 10000 in capacity and a factor 2 in rotational speed, or 20000 overall. With sqrt(20000) I get about 100MB/s, which is not too far from the real rates one would expect from modern HDs (which tur3600RPM and 700kb/s. Now we have 400GB HDs with 7200RPM, that's an increase of 10000 in capacity and a factor 2 in rotational speed, or 20000 overall. With sqrt(20000) I get about 100MB/s, which is not too far from the real rates one would expect from modern HDs (which turns out to be 80MB/s)
How do you arrive at 11Gb/s? Looks like (7.2Mb/s / 0.64 Gb * 1Tb) - That would be wrong. The areal density increases about 1560-fold (assuming 640Mb/CD), but the linear density increases only by the square root of this. The amount of data that passes by the reading laser along the track would be just 40 times larger for the holographic media compared to a CD at constant RPM, which would result in 'only' 288Mb/s. With 1Gb/s, they'd still be a factor of 4 away, but that's still closer than your estimate.
If you cannot do that sort of stuff on a modern computer (which you can, to an extent)
You just can't do the stuff the xgamestation does with modern hardware. Modern hardware has a framebuffer, but this thing has a directly controlled raster stream allowing pixel level timing and color control via software loops, so essentially you have to calculate and update the color of each and every pixel you want to display on the fly. With modern Hardware you're hard pressed to even get notified of the vertical retrace. What you learn with this thing is useless for programming modern games on modern hardware, but It may be a fun way to learn assembler (that's just an 8 bit CPU in there - they planned to use an ARM but found it "too complex") and realtime programming similar to what you would have to do on DSPs.
The only thing faster would be shared memory but that's been tried before and it's more hassle than it's worth.
Xsgi uses shared memory as the default transport for local clients, and if you ask me, it's worth every single minute they spent implementing it. X11 suffers quite badly from round trip delays, and the much faster shared memory transport really helps. If you just look how long a complex Xaw or Motif based application (with lots and lots of windows, fonts, gcs etc..) takes to start even on a fast Linux/XFree box as compared to a slow old SGI, you'll see that the SGI will be faster even if the XFree box were an order of magnitude faster. This has nothing to do with the speed of the graphics hardware, which may have been good for its time for the old SGIs, but doesn't compare too well to modern PCs. I haven't compared Linux or BSD and XFree on an SGI to IRIX on the same box. Has anyone here done this?
I've practicall only bought second hand computers and parts for the last 10 years. If you buy them from non-smoking workplaces or households, they usually have stopped stinking years ago.
There are at least two different definitions for "computer architecture" in use. One is used by hardware people, the other one by software people, the latter beeing essentially equivalent to "instruction set". You - like many other posters here - are a hardware person, the AC is not.
why Apple is so upset about Real being able to its music work in the iPod?
That one's simple: If you buy (all) your music from Real instead from Apple, you can easily switch players to another brand that also has support for Real, instead of having to buy another iPod. Remember, iTunes is just a way to sell hardware.
You're not talking about OSS itsself, but about its effect in a capitalist economy. I don't find any hint about development in your post, just about use.
The LCDs we use today are light emitting, not light reflecting. Thus, they naturally use an RGB color model. If they did not emit light on their own but only reflected like, like a sheet of paper, then their natural color model would be CYM(K).
Reflective color LCDs are rather common in PDAs and GPS receivers nowadays, and backlit advertisements are produced in CMYK, yet they emit light.
It's not about reflection or emission, but the way your components mix. If LCDs could built with stacked pixels, each blocking out part of the spectrum, they would use CMY (and have a 3x higher peak brightness), and if one could print (efficiently) red, green and blue reflective points on paper, it would be possible to use rgb in printing (but the result would probably look grey instead of white). It's only because one can easily "light" the pixels in a panel one beside the other, or further filter out part of the light by printing another layer on top of the previous one that additive and subtractive color models are used.
But not only would pixels have to be able to vary infinitely from zero to the maximum intensity you can see
The dynamic range of the eye is quite limited - That's why you have an iris to vary the amount of light that reaches you retina. Also, you don't need infinitely small ranges to adjust each color to reproduce colors indistiguishable from the original, just more than 8 bit on a linear scale (10 is good for the start, 12 should really get the job done). here is a chart showing (exaggerated) the area in which a color can vary while still remaining indistinguishable from the original for the observer.
the specific R, G, and B chosen would have to be calibrated to the viewer's cones
That doesn't seem to be necessary. Just pick red and blue far enough at the borders of the spectrum so as not to trigger the green cones, and choose a green that coincides with the minimum sensitivity of red and blue. Using rgb lasers with exacly one wavelength each, you could get close enough to to satisfy all but the few tetrachromats.
Re:New standard still necessary
on
RGB to become RGBCMY
·
· Score: 5, Informative
CMY are really "combinations" of R G and B.
They are on your standard RGB monitor, but not in the general case. For example, take a look at the CIE "Tongue" chart displayed e.g. here. With you monitor, you can only display colors in the red, green, blue triangle, but one could add pure cyan at 490nm and actually increase the area/gamut.
Second, there are colors that your eye can perceive that are not representable by the RGB system.
That would be the good old RCA, phosphor based RGB system. If you ran your display with e.g. lasers with 410, 520 and 700nm respectively, you could get a gamut that's almost indistinguishable from the full gamut the average eye can percieve. The smaller area covered in the green region on top of the chart would probably be neglegible due to the decreased capability of the eye to distinguish between greens. So, not RGB is the problem, but the technology to record and display it.
Re:Biologically speaking, how...
on
RGB to become RGBCMY
·
· Score: 2, Insightful
Some DLP projectors I think use red, green, blue, and white to get some of this contrast back.
No that's not for contrast, that's for peak brightness. Since all colors those devices can generate are linear interpolations of the filtered colors, all you can get with white thrown in is bright, non-saturated colors.
Your cyan pixel, letting through both blue and green light, would be brighter than either your plain blue or plain green or blue&green next to each other.
But you couldn't make all things brighter. If you increase the number of filters, the time and amount of light for each filter decreases. Pure red, green or blue could not be displayed as bright as before. Only colors close to those added and desaturated colors or grays would profit from this.
With all the "cheap softz" spam that's flooding my inbox, i'd expect the BSA to finally buy effective anti-spam legislation, but they haven't because their members are the same who got themselves the exceptions in CAN-SPAM.
Slashdot Mirror
Well, now that you've got a cookbook, it's probably time to think about loosing weight - well for most of the slashdot readership anyway. The proper book to do so may be John Walkers The Hacker's Diet: How to lose weight and hair through stress and poor nutrition
Could yuou please tell me what the frog is doing in there? Is he just ballast or did you train him to take the pictures at perigee?
In my estimation, every sound card (onboard or what not) is about on par with very good quality this way, since the onboard DAC isn't sending amplified trace noise out of the board.
You're right about analog noise, but sadly there are too many soundcards with digital output that support only one output frequency (i.e. either 44.1kHz or 48kHz). This makes it much easier to mix analog and digital sources to one output, but introduces artifacts due to more or less shoddy resampling - and some even show artifacts when you feed them at their preset output frequency because they resample even that.
May I suggest a Roland SC-55 instead of your old adlib card? They're much better, are relatively cheap nowadays and they even run off the serial port.
For me that would be a 10 minute (one way) ride out in the cold and/or rain (or whatever) only to find that the movie I wanted isn't available because either all DVDs are already rented out or they have stopped carrying that one because it's too old.
If you are right-handed, you would hold a chisel in your left and the hammer that usually goes with it in your right. Personally I think I would have difficulties hitting the chisel if I were operating a hammer with my left hand. One could argue that this makes writing from right to left easier, because you have to lift the hammer anyway, and to get the chisel out of the way, you only have to lift it a tiny bit and turn your hand a bit counterclockwise.
With a product that sells worldwide, you really have to ask what kind of TV tuner you expect to be put in it. A good old analog one that would be obsolete in just a few years? Or ATSC? Maybe a cable tuner, now that the cable card would allow you to use non-proprieatary boxes. Or DVB for Europe, but which one, terrestial, satellite or cable? Or maybe an analog HDTV tuner for Japan?
Personally, I'd think that some hooks, holes, clamps or whatever to strap a small 3rd party tuner like the eyeTV on the back would be the way to go.
And IBM claimed they'd intended to use paint that washes away, much like the chalk bikesagainstbush uses, but they somehow ended up using permanent paint. They ended up paying a US$100000 fine. I hope the bikesagainstbush guy has tested his paint, so that no such unpleasant surprises can happen to him.
the human eye cannot distinguish between that many shades (particularly in the blue region)
While it may seem counterintuitive, the human eye is much better at discriminating between shades of blue than between red or green (where it is worst by far). There's a nice graph showing the MacAdam ellipses that represent the amount of variation in chromaticity where no difference can be percieved in this paper. This is obviously different from the responsiveness to brightness.
16 bit color representaion usually has the 6 bits for green.
For most people, 8 bit per RGB component on an linear scale, as used in almost all computers, is not enough - you can still see some banding. A logarithmic scale or 10 bit color can fix this.
170db with a cell phone? Hardly, because it would probably just fall apart at that level, but the equivalent of 140db measured from 1m away? Maybe, since the distance is probably in the range of 5 mm, and thus just 1/200th of the distance that's usually used to take those measurments. Additionally, due to the proximity, a large part of the acoustic energy emitted by the phone enters your ear. Note that at 140db the extrapolation you attempted above fails, because at that level immediate damage may occur.
I think that the loud noise it plays is not actually the battery warning, but it's the user-defined melody the phone plays when it has finally given up and shuts down.
I fear that in the long term windows manager features will included into the X server.
That's something I'd actually like to happen - the way it was in the NEWS system (just better). In my opinion, it would actually be beneficial to replace the window manager with a script running inside the server, or even to allow application to upload scripts to the server that handle their Menus so that there are no unnecessary delays going back and forth between the X-Server and a remote client for stuff as trivial as moving a window or opening a menu.
Well, as I said, they don't just increase the data density along the tracks, they also make the tracks less wide and pack them closer together. At constant RPM, you will usually only see an increase in speed around the square root of the increase in density for this exact reason.
If speed scaling was linear in the capacity, harddisks today would have to be in the vincinity of 14 Gigabytes per second, since back in 1990 my 40MB HD had 10000 in capacity and a factor 2 in rotational speed, or 20000 overall. With sqrt(20000) I get about 100MB/s, which is not too far from the real rates one would expect from modern HDs (which tur3600RPM and 700kb/s. Now we have 400GB HDs with 7200RPM, that's an increase of 10000 in capacity and a factor 2 in rotational speed, or 20000 overall. With sqrt(20000) I get about 100MB/s, which is not too far from the real rates one would expect from modern HDs (which turns out to be 80MB/s)
How do you arrive at 11Gb/s? Looks like (7.2Mb/s / 0.64 Gb * 1Tb) - That would be wrong. The areal density increases about 1560-fold (assuming 640Mb/CD), but the linear density increases only by the square root of this. The amount of data that passes by the reading laser along the track would be just 40 times larger for the holographic media compared to a CD at constant RPM, which would result in 'only' 288Mb/s. With 1Gb/s, they'd still be a factor of 4 away, but that's still closer than your estimate.
If you cannot do that sort of stuff on a modern computer (which you can, to an extent)
You just can't do the stuff the xgamestation does with modern hardware. Modern hardware has a framebuffer, but this thing has a directly controlled raster stream allowing pixel level timing and color control via software loops, so essentially you have to calculate and update the color of each and every pixel you want to display on the fly. With modern Hardware you're hard pressed to even get notified of the vertical retrace. What you learn with this thing is useless for programming modern games on modern hardware, but It may be a fun way to learn assembler (that's just an 8 bit CPU in there - they planned to use an ARM but found it "too complex") and realtime programming similar to what you would have to do on DSPs.
The only thing faster would be shared memory but that's been tried before and it's more hassle than it's worth.
Xsgi uses shared memory as the default transport for local clients, and if you ask me, it's worth every single minute they spent implementing it. X11 suffers quite badly from round trip delays, and the much faster shared memory transport really helps. If you just look how long a complex Xaw or Motif based application (with lots and lots of windows, fonts, gcs etc..) takes to start even on a fast Linux/XFree box as compared to a slow old SGI, you'll see that the SGI will be faster even if the XFree box were an order of magnitude faster. This has nothing to do with the speed of the graphics hardware, which may have been good for its time for the old SGIs, but doesn't compare too well to modern PCs. I haven't compared Linux or BSD and XFree on an SGI to IRIX on the same box. Has anyone here done this?
I've practicall only bought second hand computers and parts for the last 10 years. If you buy them from non-smoking workplaces or households, they usually have stopped stinking years ago.
There are at least two different definitions for "computer architecture" in use. One is used by hardware people, the other one by software people, the latter beeing essentially equivalent to "instruction set". You - like many other posters here - are a hardware person, the AC is not.
why Apple is so upset about Real being able to its music work in the iPod?
That one's simple: If you buy (all) your music from Real instead from Apple, you can easily switch players to another brand that also has support for Real, instead of having to buy another iPod. Remember, iTunes is just a way to sell hardware.
You're not talking about OSS itsself, but about its effect in a capitalist economy. I don't find any hint about development in your post, just about use.
The LCDs we use today are light emitting, not light reflecting. Thus, they naturally use an RGB color model. If they did not emit light on their own but only reflected like, like a sheet of paper, then their natural color model would be CYM(K).
Reflective color LCDs are rather common in PDAs and GPS receivers nowadays, and backlit advertisements are produced in CMYK, yet they emit light.
It's not about reflection or emission, but the way your components mix. If LCDs could built with stacked pixels, each blocking out part of the spectrum, they would use CMY (and have a 3x higher peak brightness), and if one could print (efficiently) red, green and blue reflective points on paper, it would be possible to use rgb in printing (but the result would probably look grey instead of white). It's only because one can easily "light" the pixels in a panel one beside the other, or further filter out part of the light by printing another layer on top of the previous one that additive and subtractive color models are used.
But not only would pixels have to be able to vary infinitely from zero to the maximum intensity you can see
The dynamic range of the eye is quite limited - That's why you have an iris to vary the amount of light that reaches you retina. Also, you don't need infinitely small ranges to adjust each color to reproduce colors indistiguishable from the original, just more than 8 bit on a linear scale (10 is good for the start, 12 should really get the job done). here is a chart showing (exaggerated) the area in which a color can vary while still remaining indistinguishable from the original for the observer.
the specific R, G, and B chosen would have to be calibrated to the viewer's cones
That doesn't seem to be necessary. Just pick red and blue far enough at the borders of the spectrum so as not to trigger the green cones, and choose a green that coincides with the minimum sensitivity of red and blue. Using rgb lasers with exacly one wavelength each, you could get close enough to to satisfy all but the few tetrachromats.
CMY are really "combinations" of R G and B.
They are on your standard RGB monitor, but not in the general case. For example, take a look at the CIE "Tongue" chart displayed e.g. here. With you monitor, you can only display colors in the red, green, blue triangle, but one could add pure cyan at 490nm and actually increase the area/gamut.
Second, there are colors that your eye can perceive that are not representable by the RGB system.
That would be the good old RCA, phosphor based RGB system. If you ran your display with e.g. lasers with 410, 520 and 700nm respectively, you could get a gamut that's almost indistinguishable from the full gamut the average eye can percieve. The smaller area covered in the green region on top of the chart would probably be neglegible due to the decreased capability of the eye to distinguish between greens. So, not RGB is the problem, but the technology to record and display it.
Some DLP projectors I think use red, green, blue, and white to get some of this contrast back.
No that's not for contrast, that's for peak brightness. Since all colors those devices can generate are linear interpolations of the filtered colors, all you can get with white thrown in is bright, non-saturated colors.
Your cyan pixel, letting through both blue and green light, would be brighter than either your plain blue or plain green or blue&green next to each other.
But you couldn't make all things brighter. If you increase the number of filters, the time and amount of light for each filter decreases. Pure red, green or blue could not be displayed as bright as before. Only colors close to those added and desaturated colors or grays would profit from this.
With all the "cheap softz" spam that's flooding my inbox, i'd expect the BSA to finally buy effective anti-spam legislation, but they haven't because their members are the same who got themselves the exceptions in CAN-SPAM.