![]() ![]() |
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
173.200.6.182
In Reply to: RE: Well let's spread the news: MOUNT AN SSD IN YOUR cMP !!! posted by theob on February 10, 2011 at 11:08:24
maybe the fact that I am using the internal CPU in real-time to do the upsampling, etc. is why I am hearing such a difference?
At the same time I wonder if those who were not enamored of SOX and SRC might have a better impression with the SSD installed?
It could well be that if you do the processing before, and your CPU usage becomes minimal there might not be the same difference as I am hearing.
If it turns out to be an either/or thing - one can say it is much easier to just have the music on the HDD and play it instead of all of that work.
Now, the logistics of getting two, otherwise similar, cMP setups in the same room with SSD and real time upsampling and regular HDD and offline upsampling.
Being basically a lazy man who just wants to listen to music while sipping rye whiskey, I hope the SSD/real time approach is, at least, almost as good!
I do look forward to hearing your impressions with your new implementation, Theo.
Bye,
Rick McInnis
Follow Ups:
Interesting questions...now Mark listens 44k-> 44k no upsampling on the ssd and his cpu usage runs 0-1%. When I run offline upsampling off a fd I get 0-15% cpu usage (I only get the spikes at transfer from fd-> memory but there are 4 times as many transfers because of the higher native resolution). But If I run no upsampling off a fd I get 0-4% cpu usage agian with spikes @ transfer points (but far fewer transfers). Maybe that is the secret. Did you try no upsampling?
I'm starting to believe that whenever you lower power demands and burst current draw you get better sonics. I guess I gotta try an ssd.This is really facinating.
I just tried 44-> 44 off a fd and it is very close to offline up sampling off a fd sonically. I think I like upsampling better by a smidge though.
listening to it now would not tell me much,
I think the "power" aspect is important but it cannot explain everything.
When the disk drives are powered by their own supplies that argument seems tenuous to me, anyway. I can see the power argument being persuasive when it comes to power to the MB.
One would assume the more activity of the processor would, in turn, require more activity from the drive containing the OS and the software. The faster the drive can respond to requests it only makes sense this would greatly effect the function of the system. At least to my way of attempting to understand what goes on in the computer.
We have learned that speed is not important for the CPU or the memory but maybe where speed makes a decisive difference is with the drive containing the OS, the cMP/cPLAY software, or both?
It seems to me, going back to cics's idea of jitter, - this could be a source of a form of jitter if there is a lag in instructions required by the system?
Bye,
Rick McInnis
Even though the drives are powered from the outside they still generate emi/rfi on the mobo perhaps when called upon to work. Hey I'm just speculating.
Post a Followup:
FAQ |
Post a Message! |
Forgot Password? |
|
||||||||||||||
|
This post is made possible by the generous support of people like you and our sponsors: