 
|
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 |
209.130.140.130
In Reply to: RE: Feeding time at the HA zoo - again. This time main course is "FLAC vs. WAV". posted by carcass93 on February 01, 2011 at 14:31:52
If you are hearing an audible difference between FLAC compression levels on a computer manufactured in the 21st Century then you've got some serious audio playback software, OS, or Audio driver problems. Using audio playback software that supports a reasonable amount of buffering and/or forces audio data decompression to take place in its own processing thread might help alleviate these problems, however.
The idea that FLAC compression levels can influence the sound in a system that is in good working order is akin to saying that a book being read to an audience is better if it is printed in a larger font. As long as the reader is competent, the size of the font is irrelevant. :-)
Follow Ups:
"As long as the reader is competent, the size of the font is irrelevant. :-)"
Funny, that example. I recall being in just this situation one time, with inadequate borrowed reading glasses and dim light. I had to occasionally pause while I squinted to make out the letters. My audio output was jittered. :-)
FLAC (and all lossless CODECs) are variable bit rate. This entails a more complex buffering strategy than is needed for other real-time processing. Typically there will be a periodic burst of 100% CPU utilization while a buffer of FLAC is decoded. (Actually it's a bit more complex because FLAC comes in frames.) Depending on the amount of buffering used, these periodic spikes of activity can be seen by looking at graphs of CPU utilization, power supply rail voltage, and for large enough buffers, even CPU temperature and fan speed. (I have personally observed all of these variations.) The power supply rail voltage is probably the most relevant parameter and the variations will affect the clocks and other clock circuitry, and ultimately with DACs that have imperfect jitter rejection, the analog output signal. In some cases, these effects have been observed by measuring output spectra and correlating jitter peaks with system parameters.
The effects are real. Whether they are audible or not is a separate issue that depends on the DAC, the system, the listening room and the listener.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
"My audio output was jittered."
This is a hardware problem. You need to replace your optical components with a newer model.
"Typically there will be a periodic burst of 100% CPU utilization while a buffer of FLAC is decoded."
You are seeing FLAC decompression cause a 100% CPU load on a modern, multi-core system? And the power requirements for this CPU load burst is causing the signal of your digital output (which is on a different power rail than the CPU, no doubt) to change? If so, I see two solutions: 1) player software that puts a reasonable limit on how much FLAC data it asks the FLAC library to decompress at a time (perhaps this idea of decompressing before playback into a large buffer, which seems a bit hare-brained in the first place given that CPU utilization for decompression during playback into reasonably sized buffers is trivial, is not such a good one?), 2) a CPU and/or power supply upgrade.
At a certain age one wishes to replace one's entire set of hardware components with new models. :-)
100% instantaneous processor utilization for a period of time or 0% utlization. They are the only possibilities. A processor is either idle or fully utilized. (If I had a dual core system, the potential utilization would go up to 200%.) To talk about intermediate values you must result to averages, and for these statistics to be meaningful you will have to pick the appropriate time period for averaging. Someone skilled in the art of computer performance analysis would appreciate these facts.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Hi Scrith,
Why are you such a hardcore flac addict?
Face it, Flac is not the holy grail for everyone. And it does mess up some systems, especially if you do realtime upsampling. Tony is right about the spikes. I had them with flac files.
Personally I would rather give up tagging and some disk space vs. having a 3+ ghz cpu with 16gb of memory and the fans that go with it.....
I know, bits are bits. But tell me this. Do software players sound different? Do different versions of them sound different??
No one here remembers the bending of our minds
1. "... ultimately with DACs that have imperfect jitter rejection..." - no need for that, you could simply say "with DACs", or "with ALL DACs".
2. You make it sound like it's all about bursts of activity, while in reality it's just about activity - ANY processing, no matter how low its CPU utilization is, affects electrical activity (MB traffic), and ultimately sound quality.
3. It's even more than that - do the following simple experiment (I have):
Write an application, executable or Windows service, that does nothing, or polls timer every 10 minutes, so you know for sure that nothing happens in 10-min intervals, it just sits there occupying memory. To make effects more obvious, declare some buffer there, so it occupies more memory.
Compare sound quality with that application running versus not running. What do you hear? And why do you think you hear that? Is memory taken buy that app (very little!) affecting memory allocation used by media player?
It's the same effect as with disabling Windows services, only here you know for sure that app does ABSOLUTELY NOTHING.
1. Perhaps there is a DAC out there that has excellent jitter immunity and still sounds good. There is no reason to believe that such a device is impossible, just not on the market yet.
2. I was citing one specific case that is unique to FLAC. Any activity has the possibility of changing things, but this one is sufficiently gross that it can even affect fan speed. :-)
3. Two possible reasons for the differences with your 10 minute task immediately come to mind:
First, the scheduling software in Windows may not be efficient, in which case every time the O/S checks what there is to do it has more work if there are additional possible candidates. (I don't know if that is the case with Windows, but it was definitely the case with other operating systems for their networking code.)
Second, when something is loaded into memory it will affect the location of other programs that are subsequently loaded into memory. The processing efficiency may be affected because two hot loops may be loaded in such a way that they are competing for the same cache line. The exact details will depend on the processor cache design and the order and size of memory allocations.
With proper instrumentation it would be possible to observe or eliminate both of these possibilities. Obviously, for best results you need separate test equipment to observe the operating system, as a measurement process in the system will itself affect what is being measured. Neverthe less it may be possible to ascertain what is going on by careful software implementation. One measurement of OS and CPU efficiency is system idle time for a given workload. However, you can't get this accurately using standard operating system measurement (e.g. Windows task manager). The reason is that the sample interval is probably correlated with operating system timer based functions. It may be possible to measure these effects by running a low priority CPU bound process in a "soak loop" and observing how system changes affect progress of this task. (Don't try this on a system that has minimal cooling.)
I'm sure there are more possibilities, these are just two of them. I think it is futile to attempt to optimize system software without having access, at minimum, to source code.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
... gives pretty good analysis of what your, and the likes of yours, problem is.
I realize you're not going to start hearing better - but I would settle for you to at least start learning, instead of exposing your thoroughly irrelevant pseudo-knowledge at every corner.
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 © 2025, Audio Asylum, all rights reserved ]
