 
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
|
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
173.216.48.221
I recently assembled my first computer-based audio system. Following is a summary of observations and experiments for reference.Note: Most (but not all) of how I assembled this computer front end came from the Channel D Pure Music reference section here:
http://www.channld.com/computeraudio.html
(With special thanks to the Gordon Rankin and the Computer Audiophile website)
The front end is comprised of: 2011 15" 2.0 GHz quadcore Macbook Pro, 8 GB RAM, OWC 120 GB SSD internal hard drive. All music is stored in AIFF format on two OWC 500 GB portable firewire hard drives (one being the back-up for the other). The DAC I settled on is the Wavelength Proton (more on this below).
The rest of my system is a Rega Brio R integrated amplifier, Spendor S3/5R speakers and Sennheiser HD600 headphones (along with fairly fancy cables, although I consider them lesser players from experience). All of the equipment is on a Quadraspire Q4 Evo rack.
1) Pure Music definitely sounds better than Itunes. I also plan on trying Decibel, Audirvana and Fidelia at some point. I also downloaded Bit Perfect from the Apple website (it costs $5.00). Bit Perfect is an Itunes add-on like Pure Music that offers a lot of what Pure Music does (e.g., memory play).
2) Rips using the Macbook Pro's superdrive sound better than an rips using an external Pioneer optical drive even though error correction was enabled in both cases.
3) Powering the external hard drive via the optional AC wall wart sounds much better than bus powering it via firewire (and there isn't a penalty of additional noise, either).
4) The replacement internal SSD hard drive sounds MUCH better than the stock 500 GB HDD that came in the Macbook Pro.
5) Playing music stored on the stock internal HDD sounded equivalent to playing music from the external hard drive. I haven't compared playing music stored on the replacement internal SDD to the external hard drive yet. However, given the current price of large capacity SDD, this experiment isn't high on my priority list.
6) I tried 3 different USB DACs (Proton plus HRT Music Streamer 2+ and Hegel HD2). The Hegel HD2 was transparent but slightly fatiguing and austere. The HRT 2+, while somewhat veiled, was very natural, warm and musical. As expected, the Proton is definitely superior to the other two overall, especially in timing (the asynchronous aspect, I'm sure). I haven't had a chance to try the Proton's headphone output yet.
7) I didn't hear any worthwhile difference between USB cables (Audioquest Cinnamon, Wireworld Ultraviolet, Wireworld Starlight, Belkin) with the Hegel HD2 or HRT 2+. I do hear differences now with the Proton. I will be comparing USB and firewire cables again (the firewire connects the external hard drive to the computer). I will also investigate vibration devices under the external hard drive.
Edits: 09/04/11 09/07/11Follow Ups:
"6) I tried 3 different USB DACs (Proton plus HRT Music Streamer 2+ and Hegel HD2). The Hegel HD2 was transparent but slightly fatiguing and austere. The HRT 2+, while somewhat veiled, was very natural, warm and musical. As expected, the Proton is definitely superior to the other two overall, especially in timing (the asynchronous aspect, I'm sure). I haven't had a chance to try the Proton's headphone output yet."
Actually, the HRT Music Streamer II+ also uses async for its USB connection. Perhaps a better analog output stage is a more likely the reason for your observation.
Not really. Read this:
http://www.computeraudiophile.com/content/Asynchronicity-USB-Audio-Primer
Asynchronous isn't always asynchronous by strict definition. Here is the most important quote from this article:
"Asynchronous USB capable DACs are few and far between. Currently Ayre, Wavelength, and dCS are the major manufacturers with asynchronous products on the market."
Do you honestly think DAC's selling for $200-500 are going to have TRUE asynchronous code?
Gang,Look... I am not saying this is the only way to do this. But several new Async companies are not lets say optimizing the benefit of why to use Async protocol.
The best way to get the most out of a dac chip is to put 2 audio oscillators right next to the dac chip. Buffer the oscillators and send them back to the USB controller to use to create the I2S (or other audio data stream L/R justified, DSP whatever) and this will give you the best response and the lowest jitter.
What many companies are doing is using the Frequency Synthesizer to create the audio oscillators. Basically these are frequency multipliers that can create any frequency and in the case of the TAS1020 down to 4Hz resolution. The problem with a Frequency Synthesizer is that the jitter can be as much as 100x that of a fixed oscillator. When enabling the oscillator in the TAS1020 also adds noise to the audio data stream because of the noise it fixes to the power supplies.
This is what Chris was point out in the CA article.
So choose wisely what you buy and ask the correct questions.
It's not about the code... though all of ours is different, it may have an effect on the sound. But more so it has to do with the hardware and how that functions.
Thanks
Gordon
J. Gordon Rankin
Edits: 09/06/11 09/06/11
Do you really think a company would risk a lawsuit for fraud by stating something like this? Do you think Gordon Rankin or the programmer's at dCS are the only ones that know how to write code for async? Ask Kevin Halverson at HRT/Muse if his async products are truly async. Trust me, you won't ask a second time.
Do you honestly think DAC's selling for $200-500 are going to have TRUE asynchronous code?
Yes
Article is mid 2009
Today it is mid 2011
A lot of new DACs are using async USB
A couple of examples
http://www.thewelltemperedcomputer.com/HW/USB_DAC_Async.htm
http://www.thewelltemperedcomputer.com/HW/USB_DAC_AsyncSlow.htm
The Well Tempered Computer
"
2) Rips using the Macbook Pro's superdrive sound better than an rips using an external Pioneer optical drive even though error correction was enabled in both cases.
"
If files are different, at least one of the rips is bad. If files are the same and you hear the difference you have been smoking something.
"
4) The replacement internal SSD hard drive sounds MUCH better than the stock 500 GB HDD that came in the Macbook Pro.
"
If you were playing using memory play and you heard the difference you have been smoking something.
...drawing power from PSU, using system resources, and affecting electrical activity in the system.I observed essentially the same thing, when on early stages was playing with different remotes, and noticed that connecting IR USB receiver degraded sound quality to much greater extent that RF one.
Edits: 09/06/11
a spinning hdd has a seek time of 15-20mS. A good SSD 0.1mS! Consider a typical latency of 0.1 mS when playing music and one can see that seek time is much longer for the spinner
N/T
Stale,
I would agree that if the rips sound different then the files are also.
But Memory does not really make things equal. For example download and try both Pure Music and Decibel. Both use memory mode but both sound different. I can also say that in my experience the feed to the DAC is the same for both. There is no difference in jitter or distortion or anything.
But they sound different!
So let's not pigeon hole sound and why it sounds different. There is more going on here than we are looking at.
Thanks
Gordon
J. Gordon Rankin
Look also at my posts, I clearly said the same file, same software...
"But Memory does not really make things equal. For example download and try both Pure Music and Decibel. Both use memory mode but both sound different. I can also say that in my experience the feed to the DAC is the same for both. There is no difference in jitter or distortion or anything."
Gordon, your post makes two points. I have no problem with the first one, it's the second one that troubles me.
The first point is obvious to those (few?) inmates who understand how computer hardware and software both work: two programs both use memory but they use it differently. So it is not surprising that the two programs might sound different. Indeed, even if the two programs had the same source code but were compiled or loaded differently then the physical hardware would operate differently, e.g. different instruction paths and/or different patterns of cache hits/misses and data movement on the busses.
The second point is not about how systems work, it's more about how you think. The issue here is that if the two programs really sound different and this is consistent then something must actually be different. It may be on your list or it may be something that you left off your list. If it's on your list and you are unable to detect it this indicates that your detection/measurement techniques are inadequate to the task at hand. If it's not on your list it indicates that your design model is incomplete. Either way this is your problem. You can't get off the hook here because you made this statement: "There is no difference in jitter or distortion or anything. But they sound different!"
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
I am looking for parts for my 1968 zenith stereo,modle z960. Right now I need the metal bracket that has the input and output jacks incorporated in it. Also, can someone tell me where I can get some new electrolytic cans,for the main amp. This unit means a lot t6o me,and I really want to keep it working.I really need some help.Please e-mail me if you or someone you know, can help. respectfully kjayr21
Tony,
Here is the setup, the computer is 30 feet away and we are using an optically isolated cable with a linear power supply at the endpoint.
MacMini <---> optical cable USB cable <---> Total Phase USB Analyzer <--> DAC
At the DAC I have my Tek MSO scope with I2S probe attached and also the WaveCrest checking jitter on the I2S link.
With this I can verify data (with timing) at the USB link and the I2S link and verify that with the original file. Since I also have timing information I can verify that the packets are reaching the endpoint in a consistent manner.
Granted I do not have any EMI/RFI detection equipment. But since the computer is in the other room 30 or more feet away, I can pretty much declare that so low that it would not make it into the system.
So what am I missing?
Gordon
J. Gordon Rankin
"So what am I missing?"
Most likely the "DSP" between your ears is more sensitive than your measurement equipment. :-)
Here's what I'd do. I would find a way to inject deterministic jitter into the USB signal. You can do this if there is sufficient slew rate limiting and you can bias the receiver circuit. Use a sine wave signal that you can adjust over the audio range and adjust the amplitude to the point where bit errors occur and then reduce the amplitude a few dB.
Next, I would create a test file to be played through the transport, e.g. a sine wave at 3/4 of Fs/2. One can then look at the analog output of this signal using a separate spectrum analyzer. If there is not good jitter suppression one will see the sidebands from the phase modulation of the oscillator at multiples of the deterministic jitter frequency. Unfortunately, there will also be noise from the DAC (modulator noise and analog noise) and this may make it difficult to see the sidebands. If this is the case (I suspect it will since your equipment is good) then you will need to use synchronous detection in the DSP. I'm not sure exactly how to do this, but I'm pretty sure that it can be done. It might involve reading some research papers and textbooks to figure out how to do it, but more likely there is software already written to do this.
The purpose of this measurement process is to measure the attenuation of timing variations into the DAC on the output analog signal from the DAC. This is a difficult job since the required attenuation will be far more than 100 dB. I have suggested a two step process to measure this: first create a stronger signal than would occur with a (good) transport, and second provide a means of measuring the results that can go below the analog noise floor.
The test setup proposed generated controlled phase modulation of the USB signal. One could, and should, repeat the experiments using AM modulation as well. This will involve a different test setup to corrupt the USB signal. Similarly, one can use a noise signal instead of a sine wave, but then synchronous detection will be much more difficult to accomplish (e.g. much more compute intensive and require more complex algorithms).
Doing this type of work one must adapt the attitude of an experimental physicist, i.e. one must expect to have to built most of the key pieces of test equipment.
If you succeed in measuring the attenuation of the jitter modulation on the DAC output then a next step is to confirm that the injected jitter is definitely polluting the sound. (If the jitter test frequency doesn't do this then one may have to change it or go to non-deterministic jitter signal.) Another next step is to investigate modifications to the circuit, layout, etc., to improve the jitter attenuation. As with debugging radios by test signal injection it may be possible to inject jitter into various parts of the circuitry and see how much attenuation makes it out.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
"If this is the case (I suspect it will since your equipment is good) then you will need to use synchronous detection in the DSP. I'm not sure exactly how to do this, but I'm pretty sure that it can be done."
While you can build a product detector in HW or DSP, it probably isn't necessary. If you just crank up the averaging on the spectrum analyzer the effective S/N becomes large for stationary signals like your injected one and small for dynamic ones so they fade down into the grass. Of course you still see other stable signals but they should be at different frequencies. And, if they aren't, you can shift the controlled interference to a clean area.
Yes, I realize that nowadays it's all digital, but the principal is the same whether you are sweeping or FFTing.
Nice plan Tony, it will be remembered come your next review!
Rick
...are the same, the files should sound the same. Of course this is different than "error correction enabled" for both.
Item 4, the issue is not which drive is feeding the file into memory play/RAM, but what all the software is sitting on. I don't think he was implying the former. The O.P.'s points jumped around.
At least IMHO...
Steve
Software runs from memory after it has been read from a drive. Where program resides makes absolutely no difference. Only if program needs swap space, drive where swap file resides may make a difference. But that would be quite lousy implementation and it can not qualify as memory play.
The whole CD takes no more than 0.8 GB, let say that system takes 1GB and program 1GB, that is less than 3GB that even cheap bottom end computers already have. If program can not load in 1GB, fire programer. Joking aside if program is written so that takes so much memory that it can not play from the memory including music file, it is lousy program and it beats the purpose of memory play.
"Software runs from memory after it has been read from a drive. Where program resides makes absolutely no difference. Only if program needs swap space, drive where swap file resides may make a difference. But that would be quite lousy implementation and it can not qualify as memory play."
You are not considering that the disk drive (or SSD) draws power and creates noise (e.g. electrical) even if all software is executing entirely out of RAM and all music is being played entirely out of RAM. In all the cases that have been discussed in this thread the disk (or SSD) is connected to the system and powered up, even if no data is being transferred between it and the rest of the computer system during the listening tests.
If one wanted to do an experiment to see if just having the disk drive (or SSD) powered up affects sound quality even if no I/O takes place while music is playing it would certainly be possible. One would configure a RAM disk and employ boot software to load the RAM disk at system power up. Then one would boot the operating system out of the RAM disk, run the player software out of the RAM disk and access the music files out of the RAM disk. One could then experiment by electrically connecting or disconnecting the idle disk drive (or SSD). The necessary RAM disk software and boot loading software is available for various operating systems. The more bloated operating systems may need to be put on a diet before the O/S can be booted from a RAM disk depending on the amount of RAM memory that can be added to the motherboard. (The actual cost of sufficient DRAM memory to hold the most bloated of operating systems will be small in comparison to prices one pays for typical audiophile cables. :-) )
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Tony, do you understand the concept of data buffering?
Example 1: I download an audio file from the internet. The data goes through all kinds of twists and turns on its way to my browser software, which buffers this data (usually in pieces, because there is no reason to buffer an entire audio file before transmitting it) and writes it to my hard drive. Does all the "jitter" involved in the data transmission matter?
Example 2: I send audio data from my computer to an external DAC. It goes through all kinds of twists and turns inside my computer as the playback software reads it from the hard drive, buffers it, sends it to the OS's audio support library, which then sends it out via a protocol such as USB to my external audio device. The external audio device then buffers this data, because it does not want to rely on the timing with which the data arrives from the computer, and plays it back from its local buffer based on a local clock. Does the "jitter" involved in reading the audio data from the hard drive, transferring it to the OS, and then the OS transferring it to the DAC via USB matter if the external device has zero dependency on the timing with which the data arrives in its buffer (assuming there is no buffer underrun or overrun, which can be controlled via USB protocol, much like a hard drive will not let the OS send data so quickly to it that it can't keep up when physically writing it to the disk)?
If so, please explain why this external DAC, which is buffering the data and therefore has no dependency on the "jitter" of the incoming data, and which is controlling data transfer from the transport (the computer) so as to prevent buffer overruns and underruns, has any dependency whatsoever on the machinations of the transport (and why this case of transport feeding DAC is different from the case of internet feeding storage hard drive).
"Tony, do you understand the concept of data buffering?"
Of course. Have understood this, designed real-time operating system software, firmware, device drivers, communications protocols, etc. for over 40 years.
"If so, please explain why this external DAC, which is buffering the data and therefore has no dependency on the "jitter" of the incoming data, and which is controlling data transfer from the transport (the computer) so as to prevent buffer overruns and underruns, has any dependency whatsoever on the machinations of the transport (and why this case of transport feeding DAC is different from the case of internet feeding storage hard drive)."
Because the designer of the external DAC did not do a sufficiently competent job of design. For more details, you will have to contact the individual designer as I am not privy to the necessary proprietary information.
Now it's my turn to ask questions:
1. Do you know what EMI/RFI is and how it might affect the operation of a DAC?
2. Do you know what an eye pattern is and how this relates to the operation of a DAC?
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Now it's my turn to ask questions:1. Do you know what EMI/RFI is and how it might affect the operation of a DAC?
I know what EMI/RFI are, but I do not know the specifics of how these effect the internal electronics of a DAC. I'm unsure what this has to do with a DAC's dependency (or lack thereof) on jitter from data it receives from a PC (which, one would hope, is irrelevant through the use of basic data buffering in the DAC), however (assuming the DAC is properly shielded from the levels of EMI/RFI one would expect in an environment containing nearby computers).
2. Do you know what an eye pattern is and how this relates to the operation of a DAC?
I've observed these on oscilloscopes with my Dad (an electrical engineer), but, again, I am unsure what this has to do with a DAC's incoming data (assuming it is properly buffered, as it would be in any other device that has a dependency on the speed at which it uses the incoming data, such as a hard drive).
Edits: 09/08/11
Thank you for your honesty.
It now appears from Gordon's description of his optically isolated test setup that the effects he was observing did not come from emi/rfi coupled through the air or the transport DAC connection. Assuming that it's not the power wiring (something that could be tested by running the computer entirely off of batteries if that wasn't already done) one is left with variations in the waveforms traversing his optical USB extender.
The significance of an eye pattern is that it shows the presence of information on the cable in addition to the 0's and 1's that are the reason for existence of a "digital" communications channel. These demonstrate that physical reality is not just 0's and 1's due to various forms of signal degradation, viz. rise time, droop, jitter, noise, ringing, and what not. Eye patterns are the living proof that all signals inside computers, and especially on longer signal runs between computers, are not 0's and 1's, but are much more complicated. Unfortunately, human hearing has a dynamic range beyond 100 dB and looking on scope traces one can see noise and distortion no more than 60 dB down (0.1%) and in most cases no more than 40 dB down (1%). So the interesting activity from an audio perspective is hard to see on a scope trace. Specialized (read expensive) equipment is required to go beyond this level. But putting a scope on just about any signal involved with a computer is all that it takes to prove decisively that "bits ain't just bits". This is all well known to computer hardware designers, who are trying to make the signals better so they can run the machine faster or trying to make the signals worse so they can built the machine cheaper so long as it is still sufficiently reliable that they can keep their job. (I worked as an engineer for a large computer company for over 25 years.)
All of this is why buffering is not the whole story, since the buffers are supposedly dealing with bits whereas in reality they are dealing with analog signals, as can be seen by looking at eye patterns.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
"...something that could be tested by running the computer entirely off of batteries if that wasn't already done"Gordon used a Macbook running off it's internal battery for the test he described.
"...since the buffers are supposedly dealing with bits whereas in reality they are dealing with analog signals"
Tony,
Does it seem possible (to you) that poor quality of the analog signal being interpreted/analysed by the USB receiver chip could stress (or otherwise impact) the chip's performance in such a way that other aspects of the DAC's performance (such as it's clocking function) could be impacted?
clay
Edits: 09/09/11
"Does it seem possible (to you) that poor quality of the analog signal being interpreted/analysed by the USB receiver chip could stress (or otherwise impact) the chip's performance in such a way that other aspects of the DAC's performance (such as it's clocking function) could be impacted?"
It's certainly plausible. One would have to know more about the innards of the USB receiver circuitry. At least one can be quite certain that the timing of operations done by the receiver chip will be affected by the waveform that arrives. As a result, the pattern of electrical activity inside the walls of the DAC box will vary as a function of the signal quality entering the box. Whether or how much this affects the analog output depends on factors that only Gordon is privy to.
For another example of how this happens, one can look at the ESS SABRE chip which includes an SPDIF receiver. The timing of the SPDIF receiver circuit operation can definitely affect the analog output of the chip and this issue was specifically discussed by the chip designers in their technical white paper. As I recall, they put the high power circuitry off chip as a result of this issue.
In addition the data must be buffered and reclocked somewhere inside the DAC. Even if there is no coupled noise on the clock circuitry the timing of the data arriving at the buffer register will vary with the operation of the USB receiver circuit. It is possible that this will modulate the output of the buffer, depending on the circuit design, layout, power and ground associated with the buffer circuit. Digital buffer circuits are generally designed to reduce input variations in their output signal to a certain amount but what is needed for correct operation of downstream digital logic is far less critical than what is needed when the output signal is turned into an analog signal. (So, for example, if there is a 10% variation in clock timing or a 10% variation in signal levels or a 10% variation in rise time this will have no effect on downstream logic, but if this variation appears at the actual switching circuitry it will utterly destroy the performance of a DAC.)
In principle one could run circuit simulations of the buffer and clock circuitry and see how well they filter out these variations, assuming the circuit design details were somehow available. (These will be available to designers of mixed signal components such as DAC chips, but I don't know about DAC designers who buy their logic components off the shelf.) In addition, simulations are only useful if they can be validated by real-world data otherwise one is dealing with an unproven model. (That's the problem with the "scientific" predictions of global warming based on computer models.)
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
"It's certainly plausible."
Thanks Tony, I've wondered about this for a long time, but assumed that since no one else seemed to be suggesting this as a possible explanation - for say, why usb cables or software can make a difference - that it must not be possible for reasons I didn't understand.
thanks, as always, for your cogent explanations.
clay
=========
Do you know what EMI/RFI is and how it might affect the operation of a DAC?
=========
May I ask a related question? How do you know how the player, being one of the many processes running on the general-purpose OS like windows, which you have no control over due to its proprietary and closed nature, consuming a tiny fraction of the overall momentary CPU/memory/busses (the update of the player GUI takes most likely more resources than the actual real-time audio playback, incl. decoding from flac) affects the overall EMI/RFI level on the vast range of PC hardware people use here on a consistent basis to be able to state which player sounds better? IMO everything matters, but the actual player process effect on the resultant EMI/RFI noise cannot be consistently recoqnized on as complex OS as windows with graphical interface and tens of other running processes and threads, where many are most likely not listed in any API available to programmers outside of microsoft. Yet many recommendations are being presented as a generally working truth.
The same level is distinguishing the sound of bit-perfect and correctly coded players playing from RAM by compiler version. Or another statement arising in this type of threads: drivers compiled by different compiler sounding different. Plus I doubt anyone has even access to such specimen as these claims are mostly done by people using closed systems without access to drivers source code to re-compile for proper listening tests.
haering all these differences because nobody knows what is actually going on in the replay chain.
Many simply treat processess as black boxes (like ram which itself is an edge-triggered device of which there are many in a computer) providing idealised data transfer. This load to ram giving different sounds is one of these deabtes that can go on forever unless the detailed process transfer functions can be identified and followed wrt to time.
Hi Phofman,
How do you know how the player, being one of the many processes running on the general-purpose OS like windows, which you have no control over due to its proprietary and closed nature, consuming a tiny fraction of the overall momentary CPU/memory/busses (the update of the player GUI takes most likely more resources than the actual real-time audio playback, incl. decoding from flac) affects the overall EMI/RFI level on the vast range of PC hardware people use here on a consistent basis to be able to state which player sounds better?
Man that was one hell of a sentence!!
You might not have seen the cmp2 project. While your point is valid for most, I am not sure it applies to inmates who have a cmp2 box. First of the OS is seriously detuned. No internet, no fancy gui (the graphics driver is removed with the cpu handling the video, which is detuned to 8bit color with the player basically white and black and even the number counting can be removed), less than 10 processes running. Much of the os is removed as is winlog. Memory is minimal, and the hardware is more or less consistent.
Recently there have been threads about removing even more of the os, like many dlls for things that probably arent even used. But all that affects the sound.
At least with this project it seems that there is some consensus as to what affects sound and AFAICT in this project the OS is controlled enough to draw some conclusions...
No one here remembers the bending of our minds
Here's what I know.
1. Changing player software has affected the sound on both my Windows computers (one PIV XP Pro with 1 Gig RAM, one I5 W7 Pro with 12 Gig RAM).
2 The effect on sound persists when the players compared are running in a bit perfect mode, i.e. delivering the exact PCM samples without any gain changes, resampling or other DSP. In several cases, this was verified by loopback tests.
3. The load averages you quote are probably derived from samples taken by the operating system. From considerable experience with computer system performance analysis I know that these statistics are not to be trusted, as the sample times are correlated with operating system activity and usually underestimate operating system overhead.
4. Audio activities tend to be periodic and are related to buffer sizes, e.g. the size of disk buffers, the size of buffers used for lossless decoding, the size of buffers used by the sound card, etc. When buffers are being filled or emptied, the CPU overhead is temporarily 100%, and this constitutes a periodic demand that manifests in periodic currents on power and ground traces, etc.
5. It is possible to detect (measure) the effect of these periodic cycles in the output of DACs, as the jitter spectrum is affected by these cycles. The effect of these can be seen as sidebands from the phase modulation of test audio signals and the sidebands move as software buffer parameters are changed. These effects have been measured by researchers.
6. When you listen to music through a DAC you are listening to the clock, much as when you listen to an LP you are listening to the motion of the turntable platter. The clock is affected by electrical noise and also mechanical vibration. In addition, the distribution circuitry between the clock oscillator and the actual switching circuits in the DAC is affected by small amounts of noise in the power and ground wiring of these circuits which move the switching threshold and thereby introduce jitter in the effective clock. That's a known physical mechanism for how EMI/RFI can make it through to the analog output of a DAC even if the clock in question is supposedly local to the DAC.
7. Most of the supposed Operating System overhead is transient and depends on user action, e.g. the overhead of graphic eye candy exists only for short bursts of time as in moving windows around, etc. These do not represent a continuous and incessant impact on the sound that gets attributed to the musical reproduction.
8. Some of the common audio players may have "low overhead" measured on average as you suggest, but when looking at system statistics these still manage to be one of the largest consumers of system resources.
9. With the memory playback software that I use (cPlay) I do not hear any difference between playback of FLAC and playback of WAV files. This is not surprising, because cPlay nearly always completes all the necessary FLAC decoding at the start of each track, generally a silent period where there is no music playing.
10. Many audiophiles note differences they hear. Some are more careful experimenters than others. Some may correctly attribute causes to the effects they hear, others may not. This does not make their work insignificant or useless.
11. The posters who are reporting on compiler changes are often the authors of the software and the person who ran the compilations involved. Presumably they have debugging tools and can tell what is happening inside the operating system. None of this is to be considered "magic" in any way. The same goes for driver software. In any event, for most people who aren't doing compilations they do their testing in terms of specific program release versions and I don't find most of these people talking much about compilers.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
agree with you, with 2 exceptions.
1. cPlay does not sound better than other players and different 'much improved' versions sound very significantly different from each other. The use of ASIO and upsampling also clouds the picture. KS sounds quite aabit better using other players.
2. Loding into RAM does not always sound better than playing off HDD which is properly isolated. I am loading my best sounding music onto a SSD which is sata connected for comparison with a spinner. So far, it sounds better. The interesting things is that bass calrity is particularly affected using different hard disks.
You are particularly right about processess and resources. A large number of cMP process and hardware 'killing' actually do nothing, and some that seem to do sound worse.
My pc audio system has 250 MB Windows WinXP install and consumes nearly constant cpu and memory resources when playing music. There is no cyclical reading to ram. Every possible voltage rail is silenecd or separately regulated. Connection of the keyboard and mouse affect sound adversely and so there is none of these when playing. Impedance matching and cabling to external dacs is very important.
Recompiling with different settings, that is. I posted on this before. All ingredients are freely available - source code, ASIO SDK, and Intel compiler (or GSL, if you prefer so).The difference is SIGNIFICANT - and easily detectable, since you can almost instantly switch between different versions.
Generally, in my system and to my ears, the best sounding version was the one with almost all code optimizations disabled. WHY? That's interesting question, but in my opinion secondary to the fact that it does sound different.
PS: One notable exception is the usage of Streaming SIMD Extensions (SSE), with code that utilizes the highest spec allowed by particular CPU sounding noticeable better. Even better would be to not leave it up to complier to optimize code by converting legacy code to SIMDs, but do it yourself explicitly. Unfortunately, that is above my competency level.
Edits: 09/06/11 09/06/11
I don't have access to software to assess accuracy, but I have heard multiple instances of particular discs when ripped better drives or better software sounding much superior. I know you will say I am smoking something but it must be mass hysteria as I have often demonstrated this repeatedly and the authors' of the software and of the Empirical Audio system rightfully proclaim this.
I never said that "bits are bits" when obtained from different sources. Jitter, and the whole process of DA conversion may be different....
However, once read in to the memory, and played from memory with the same program and hardware, not read in chunks from the drive or other source, or through different software/hardware that difference goes away.
You have the same file (read from wherever you had it) in the same physical location (memory), converted by the same program/process.
If you hear the difference that you have been smoking something.
Alternatively, the source files are not the same or memory play is not actually so, or there are variables in the computer that affect the play over time.
But none of those has anything to do with the original source of the file.
It is possible that "...instances of particular discs when ripped better drives or better software sounding much superior" but only for one reason, resulting files were different (because of reading errors).
There are number of ways to compare audio files, just Google it.
Easy one is you started ripping form the same CD would be checksum command.
Those on the Mac were read by Itunes onto its SSD. Those on the TuneBankHDD using software from Empirical Audio. The Mac PowerBook Pro playing Pure Music is used on that side. The TuneBank is connected with eSata to a modified Mac Mini and also uses Pure Music. In every instance the Empirical Audio system is far superior. I suspect a better read in ripping is part of this improvement. I thought you were arguing that an accurate rip is an accurate rip.
Accurate rip is accurate rip, resulting files are the same, period, dot, end of the story. If files differ, than at least one is not an accurate rip.
Only difference you can hear is if one of the software/hardware goofed and did not provide accurate rip (for whatever reasons), therefore, resulting in two different files.
I will stay to my original statement that those who hear difference between identical files played by the same software+hardware from the memory based on the origin of the files are deluding themselves.
But they are free think and spend their money wherever they want.
a
Norm,
If you rip a file twice you will get two files. Even if the two files contain the exact same bits they will be stored in two physical locations and hence will not be identical. It is possible that repeating a rip twice using the same software and hardware may produce two files that sound different. The same argument applies where two different drives are used, but here there is the likelihood of an incorrect attribution: the natural human tendency will be to attribute a difference in sound to the change in drive used to make a rip. The situation can be more complex. Different drives rip at different speed and use different strategies for error recovery. This affects the timing of successful reads and hence the timing of disk writes to hard drive. This provides another possible means of minute variations in the physicality of the "identical" bits. It is impossible to predict exactly what is happening, for example it depends on relative rotation rates of media and their effect on rotational latency of disk I/O. This makes it difficult to conduct proper experiments, especially since the details of the underlying processes are likely to be proprietary.
If one incorrectly attributes differences in sound to the drive used to make a rip rather than to the ephemeral details of computer operation one will have gained false knowledge. Such false knowledge will not be useful to the typical audiophile goal of improved sound. Unfortunately, most audiophiles conduct these kinds of experiments, especially if they lack the engineering knowledge of how the underlying system might work. Unfortunately, the process for correct attribution of causes of different sound is difficult and time consuming. One needs to treat it as a typical statistical experiment, involving many rips of the same disks performed in a different random order. Ideally, one will reformat the drives a number of times in the experimental sequence or use special file system tools to control where the rip images are going. I don't think this approach is practical, but if it hasn't been done it is incorrect to attribute different sounding rips to different drive sources. This kind of careless or ignorant experimentation is one reason why many audiophiles "spin their wheels" while trying to improve their systems.
There is a better way to deal with system factors during ripping. One simply rips to one volume but uses this rip as a temporarily file. One then uses the operating system file copy utility to copy the ripped folder to the volume where it will finally reside in your library. This will remove most if not all the effects of timing variations during the rip process. It also have the advantage that the files on the library volume are much less likely to become fragmented. In general, if two identical files (identical as confirmed by a file checksum such as an MD5) sound different, my suggestion is to copy one or both of these files and then compare these copies to see if the difference is preserved across the file copy. One can copy several generations if one wishes.
My comments apply to spinning rust only. I don't have experience with solid state disks, but I do know that firmware inside them is complex and highly non-transparent, making experimentation more difficult. However, I still believe the strategy of ripping to a temporary volume and recopying to the library volume is a good one. This has been my practice for a number of years for various reasons, mostly because I don't like to disturb the contents of my library volume more than necessary out of paranoia. I only want good rips to ever get stored in my library.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Tony,Great post.
"This will remove most if not all the effects of timing variations during the rip process. It also have the advantage that the files on the library volume are much less likely to become fragmented."
I've long assumed that fragmentation and/or file location on the drive could be the cause for reports of identical files sounding different.
What do you see as the possible effects of timing variations of the rip process, other than fragmentation?
thanks
clay
Edits: 09/07/11 09/07/11
"What do you see as the possible effects of timing variations of the rip process, other than fragmentation?"
If the data is made available to the OS to be written into a file then the location chosen may depend on the timing, e.g. if there are other files being written at the time. If one is curious one can investigate the LBNs (logical block numbers) assigned by file by using disk level tools that access the file system metadata. However, even these tools will not necessarily show precisely where on the physical disk (cylinder, head, sector) the data is stored because disk drives perform a certain amount of re-vectoring of bad sectors. There are disk diagnostic tools that my help here, but I can't comment about these, as I have no experience with them.
However, in addition to where (sector) data is stored the actual location of the bits themselves (the magnetic patterns) depends on an interaction between application software, operating system software, drive firmware and the timing of disk rotation. The details of this operation will be proprietary to the individual disk drive, but it may be that there are different modes of writing (single sector, multiple chained sectors) and these have different timing due to second order hardware interactions. In addition, the drive write circuitry has to time the start of writing off of data read from the disk and the timing of this will be affected by noise. In extreme cases a read error at the critical time may cause data to be written in an incorrect place, causing data corruption, but I wouldn't expect this to happen with modern disk drives. (This did happen once many decades ago and was a mysterious problem that took months to diagnose and cure as it involved a combination of drive hardware, controller hardware and operating system software. I was on the periphery of this investigation but was familiar with it in some details as I had originally proposed that the disk controller have a number of performance optimizations that improved system throughput, but also made operation flaky on certain lots of disks because of an interaction between controller design and the encoding structure of data on the disk.)
Apart from gross changes such as fragmentation or soft read errors, it's hard to imagine how location will affect the sound out of a DAC, but I wouldn't say this is impossible. That's why I suggested recopying the data and comparing the copies. Of course any of these low level changes in the computer system should have no affect whatsoever on a properly designed outboard DAC. Unfortunately, most DAC designers won't accept responsibility for this situation and those that do throw up their hands and don't know what to do about it. Hopefully this will change and then this discussion will become academic.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
you are now open to two rips sounding different, for whatever reason.
For the average user, there is no distinction between what goes on inside a PC, and what goes on inside different cdrom drives; the resulting differences are parts of computer operations.
Basically, bits are not bits and the temporal nature of streams can come into play
"you are now open to two rips sounding different, for whatever reason."
I have always been open to rips not sounding the same. This includes rips producing different bits, and rips with identical bits sounding different, possibly on account of where they are stored in the computer system. I began playing with computer audio back around 2005 and within a few months discovered that bits didn't get read/written on CDs reliably, that the operating system software often changed the bits in unpredictable ways, and that even when identical bits were sent to a DAC the resulting sound could be different for reasons that were not readily explainable.
The issue isn't whether "bits are just bits", it's what to do about the situation that "bits aren't just bits".
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
nt
___
Fearnor's Stereo Configuration
"I don't have access to software to assess accuracy, but I have heard multiple instances of particular discs when ripped better drives or better software sounding much superior. I know you will say I am smoking something but it must be mass hysteria as I have often demonstrated this repeatedly and the authors' of the software and of the Empirical Audio system rightfully proclaim this."
It is possible to examine the rips and see if they are the same. This is the first point in any process of improving the sound quality of one's rips. Trying to evaluate why sound quality differs without using tools to do this is like looking for a lost object in a pitch black room without using a light.
Note: if you use different software for doing rips then the files created are very likely to be different. Whether the differences will matter or not will depend, among other things, on the software used to play them back.
Note: If you use the same software and rip a disk on two different drives then the files created are very likely to be identical if the disk was in good condition and if the ripping software for both drives has been correctly calibrated as to offset error. Low quality ripping software, such as iTunes provides no way to adjust offset errors and hence it is likely that using this software will produce drive dependent results. Poor results are due to using crappy software, not a crappy drive for the actual rip.
Note: If you use the same software and rip a disk on two different drives it may make a difference if the disk is in poor condition, as some drives do a better job of reading certain defects (scratches, pit rot, etc.) than others. If you use decent software you will get an error report and if there were errors then you can try using a different drive. Often one drive will be better than another at reading most damaged disks, but this will not always be consistent and other disks may work better with a different drive. Again, junk ripping software such as iTunes will not tell you about most problems while ripping and the result may be inferior sounding rips with some drives. This is the fault of crappy ripping software.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Regarding ripping, I compared several different albums this way. Apparently error correction alone is not enough to overcome USB vs SATA interface differences, or differences in quality between drives. Try it yourself if you think I have tin ears.
Likewise, try the SSD vs HDD thing yourself. If I didn't hear a difference with the SSD then I was going to return it for refund.
You are not talking about memory play, put playing from drive, different thing.
Sure. Though there are several inmates who use a cics memory player (which interestingly enough plays files from memory) and have put in ssds. I cant think of one who did not say it was better than the normal hdd.
I can think of many things that can affect the sound that are different with ssd: Vibration, magnetism, power draw, etc.
No one here remembers the bending of our minds
"4) The replacement internal SSD hard drive sounds MUCH better than the stock 500 GB HDD that came in the Macbook Pro. "
""If you were playing using memory play and you heard the difference you have been smoking something."
Perhaps you're the one smoking something if you Don't hear a difference. Even using memory play, the SSD sounds better than the stock HDD when used just for the OS.
Edits: 09/04/11
You are not talking about memory play, but playing from drive, different thing.
Lets see- I'm talking about the the internal SSD used for the OS and the external HD containing the music library. And I am loading the entire music file into memory for playback via a program like Pure Music.
Far out isn't it! This isn't new stuff here. We have been discussing this since 2008. Do a search if interested.
between the fully loaded file and programs in to the memory due to different source (drive) of the file that is fine with me.
You are free to spend your money for whatever you want.
Well in that case, it's time to do The Stroll.Now I feel better.
Edits: 09/04/11
Some people on forums just seem to look for things to argue and dispute (especially here in AA).
I don't understand arguing the theory and application of ripping, memory play, SSD, etc. In the end it either sounds better to me or it doesn't. Simple.
And I thought I was anal for doing all of these experiments.
What you won't hear from these people is that they have tried what you have and have reached a different conclusion.
They hadn't tried it; just theorising based on black boxes that just do the 'magic' process 'tranform'.
There are no perefct black boxes in life.
> 4) The replacement internal SSD hard drive sounds MUCH better than the stock 500 GB HDD that came in the Macbook Pro.
In that the SSD is silent? Or are we talking about the audio data stored on these devices...
The SSD is strictly for the OS. All music is stored on external HDD
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:
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2024, Audio Asylum, all rights reserved ]
