41.183.0.21
| '); } else { document.writeln(''); } } else { document.writeln(''); } } else { document.writeln(''); } } // End --> |
In Reply to: RE: cPlay - the open source high-end audio player using ASIO posted by cics on May 05, 2008 at 12:31:58
Refer to ReadMe.txt for important details & specifications.
Change Log (2.0b31 release):
- DSP refinements
- Threads optimisation for use with cMP's "Realtime" Optimise setting. Recommendation of "Critical" setting remains however significant efficiency gains makes "Realtime" a strong option.
This allows for complex decoding (i.e. FLAC) to occur without affecting playback in cMP. Depending on soundcard ASIO driver, "Realtime" setting could be better.- SRC efficiency improvements reducing CPU load and L2/L3 cache footprint
- Minor refinements
- Added support for "Tiny" DSP Buffer Size. Previous buffer options remains the same with "Auto" using either "Small", "Medium", or "Large", i.e. "Tiny" must be manually selected.
"Tiny" buffer option reduces L2/L3 cache footprint enabling lower specification CPUs to be used with resampling. The 2MB L2/L3 cache requirement remains to produce highest quality 192k output.
cPlay documentation can be found at the new cMP² website. cPlay 2.0b31 offers significant SRC processing improvements and remains the reference resampler. Those not using SRC should re-evaluate this. "Tiny" buffer setting is also highly recommended (especially in combination with SRC).
Please REMOVE previous versions before installing cPlay 2.0b31. Normal (SSE2), SSE3 B9, SSSE3 B9 and SSE4 B9 versions are available. Running cPlay on a CPU not supporting the required instruction set will cause cPlay to exit immediately. For best results, uncheck "Timer" setting and test different "Buffer" sizes.
Putting things into perspective
Changes are readily observed with each new release. What follows is a technical explanation of why this is so. Modeling (Periodic) Jitter Theory for a wide range of Jpp using a frequency sweep of the audible range and beyond yields the following:
Practical implications are profound as such Jitter Distortion damages sound quality:
- Sideband distortion rapidly increases with input frequency, i.e. high frequency sounds are most affected. This is seen in the rapid rate of distortion increase as frequency rises. Critical harmonic sound information in this HF band (delivered by tweeters) is distorted. This has detrimental effects such as veiling, poor transients and poor tonal decay.
- Most important insight is the extent to which Jpp must be reduced.
- We see that for high Jpp (150..350ps and beyond) an audio designer is not well rewarded for Jitter reduction efforts, i.e. despite large scale drop in Jpp, distortion levels remain stubbornly high. Modern DACs (including some soundcards) have an excellent noise floor of -118db or better. This implies that jitter distortion arising from HF input (above 5kHz) will be well above such noise floor. For example, an input tone of 10kHz and Jpp at 150ps would yield sideband distortion of -112.6dbFS. Ouch!
Interestingly this explains why some reviewers unexpectantly express disappointment with front-ends offering ~200ps Jpp performance. That is, the noise floor is polluted with excessive sideband distortion.
This may also explain why some vendors have become disillusioned with Jitter and have abandoned it's role as a major source of audible distortion. Sadly, others have yet to understand how to measure such distortion (which can only be done correctly at the analogue outputs).- Implications for poor setups with Jpp above 150ps suggest sound quality improvements will not be easily experienced. Perhaps this explains why some object to for example RAM size, quality & setup to have sound quality impact.
- Much to our relief, distortion drops rapidly below 150ps Jpp. As can be seen, for each 50ps drop, distortion reduces in ever increasing drops. That is, we see an exponential decay. Consider for example 50ps Jpp, any improvements here will have factors more benefit than with same improvement at higher Jpp. This suggests high quality setups like a fully specified cMP (whose measured jitter performance is 51ps Jpp RSS using foobar) would be significantly better at revealing improvements.
- For the ideal case, jitter performance results in sideband distortion for all input frequencies below the DAC's noise floor. A noise floor of -130dbFS, requires jitter performance below 10ps Jpp! Intel's new 32nm Nehalem platform is a good step forward.
Rarely does theory and practice meet so beautifully. The efforts of Julian Dunn who laid the foundations for understanding Jitter and its challenges is truly remarkable.
Follow Ups:
Post a Followup: