Audio Asylum Thread Printer

Get a view of an entire thread on one page

Computer Audio Asylum

cPlay 2.0b26 Released

41.183.0.21

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.0b26 release):

Increase support for large WAV files to 4GB (from 2GB)

SoX 14.2.0 resampler implemented. Settings allow for VHQ (Very High Quality) or HQ (High Quality) converters. Important resampler effects includes phase, bandwidth and (above bandwidth) aliasing.

DSP and ASIO refinements

Added SSE3 B9 version for CPUs supporting SSE3 but not SSSE3. SoX resampler is not compatible with a compiler optimisation. This impacts SSE2 and can be avoided by using SSE3 or higher versions.

UI allows for most settings (excluding ASIO, Output Rate, Buffer & AWE) to have immediate effect. "Apply" button in Settings applies new settings during playback enabling easy comparisons.

Improve UI (new icons and enhanced Settings window)

Enhance gapless processing and background loading

Please REMOVE previous versions before installing cPlay 2.0b26. 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 cMP² users, review these BIOS changes (underclocks FSB, CPU & disable additional USB items). New settings are in effect allowing for lower power consumption (below 20W). Recommended Gigabyte mobo GA-G31M-S2L is no longer available, use either GA-G31M-S2C, GA-G31M-ES2L or GA-EG45M-UD2H (advanced settings discussion).

SoX 14.2.0 Settings

SoX implementation in cPlay enjoys full optimisation as that for SRC (Secret Rabbit Code). This includes 128bit DSP processing and other optimisations. Only VHQ (Very High Quality, 175db rejection aka Stop Band) and HQ (High Quality, 125db rejection) converters are supported. SRC at 145db SNR (154db rejection) and 121db SNR (120db rejection) remains as before. SoX VHQ offers better than 170db SNR performance (see measurements below). Other SoX resampler options available in cPlay are (as per SoX Manual):

Phase (0-100)

All resamplers use filters that can sometimes create `echo' (a.k.a. `ringing') artefacts with transient signals such as those that occur with `finger snaps' or other highly percussive sounds. Such artefacts are much more noticable to the human ear if they occur before the transient (`pre-echo') than if they occur after it (`post-echo'). Note that frequency of any such artefacts is related to the smaller of the original and new sampling rates but that if this is at least 44.1kHz, then the artefacts will lie outside the range of human hearing.

A phase response setting may be used to control the distribution of any transient echo between `pre' and `post': with minimum phase (0), there is no pre-echo but the longest post-echo; with linear phase (50), pre and post echo are in equal amounts (in signal terms, but not audibility terms); the intermediate phase (25) setting attempts to find the best compromise by selecting a small length (and level) of pre-echo and a medium lengthed post-echo. Note that phase responses between `linear' (50) and `maximum' (50..100) are rarely useful.

Bandwidth (90-99.7%)

Band-width is the percentage of the audio frequency band that is preserved. A resampler's band-width setting determines how much of the frequency content of the original signal (w.r.t. the orignal sample rate when up-sampling, or the new sample rate when down-sampling) is preserved during conversion. The term `pass-band' is used to refer to all frequencies up to the band-width point (e.g. for 44.1kHz sampling rate, and a resampling band-width of 95%, the pass-band represents frequencies from 0Hz (D.C.) to circa 21kHz). Increasing the resampler's band-width results in a slower conversion and can increase transient echo artefacts (and vice versa).

The -s `steep filter' option (99.0% bandwidth) changes resampling band-width from the default 95% (based on the 3dB point), to 99%. Band-width values greater than 99% are not recommended for normal use as they can cause excessive transient echo.

(Above Bandwidth) Aliasing

Aliasing above the pass-band is allowed. For example, with 44.1kHz sampling rate, and a resampling band-width of 95%, this means that frequency content above 21kHz can be distorted; however, since this is above the pass-band (i.e. above the highest frequency of interest/audibility), this may not be a problem. The benefits of allowing aliasing are reduced processing time, and reduced (by almost half) transient echo artefacts.

Resampler Measurements

All output files are generated from cPlay. Both 16/44.1 and 32/44.1 1 kHz test tones are used:

Upsampling 16/44.1 > 192 (SoX -vLb99.7 on left and SRC 145db right):

A closer look at the bandwidth option using 16 bit test tone (noise floor ~130db):

SoX at 99.7% offers all frequencies up to 22kHz (max is 22.05kHz). SRC offers ~96% and cannot be changed.

Upsampling 32/44.1 > 192:

Downsampling 32/192 > 44.1:

SoX SNR is better than 170db whilst SRC is better than 150db (notice small artefact ~150db above 20kHz).

Phase measurements done using a 2kHz (2 cycles per ms) 24/44.1 test tone. Transient is a sudden volume increase (50db) from -90dbfs to -40dbfs for 5ms:

SRC output at 192:

Both pre- & post-ringing is equally distributed.

SoX output at 192 (minimum phase):

No pre-ringing but greater post-ringing. Overshoot and ringing level is greater than SRC (due to higher rejection db, higher SoX bandwidth and no aliasing). Note that:
SoX non-linear (non-50) phase setting affects HF phase response of original input signal (i.e. a trade-off is made wherein increasingly higher frequencies undergo greater phase shift). Intermediate setting (anything between 0..50) offers better balance regarding this trade-off.
Observed ringing is beyond human hearing when "min(input, output)" is 44.1k or larger.
Ringing effects can be further reduced when "alias" setting is enabled. This results in a trade-off wherein alias artefacts above Nyquist cut-off is added, e.g. for 44.1k input and 192k output, distortion above 22.05kHz occurs. These levels are low (below 100dbRMS) and not in the audible range.

cPlay 2.0b26 (1.3MB) (Open in New Window)

Follow Ups:

the dubious pleasures of resampling - steppe 13:21:27 05/30/09 (12)
Hello, everybody! I know that many people like resampling to 96, or even 192. As I work in graphic design sphere, I often come across images, resampled by other people, who do it to conform to printshop standards. As our wave files can easily be represented, and they are (in professional programs like samplitude), as a black&white image, it is very easy to understand with the above picture, what resampling does to original image (wave). On the picture You see a detail of my cat. To the left - non resampled original (16 bit 44,1 kHz), to the right the same image (resampled 400 % - read to 96 kHz) The arrows show artefacts of resampling. Take a close look. Resampling was done in Photoshop, the king of professional image processing, so it can be compared to Sox or SRC.
If you watch carefully you will certainly find more. To better see the difference, save the image and zoom in on it in picture viewer program.
This is by no means to discourage You from resampling, I thought it might be interesting to represent the fact this way
Serge.
- If it looks or sounds better then - audiozorro 10:07:23 06/01/09 (0)
  IMO the pleasures are not dubious. Similarly, if something looks or sounds worse then IMO the shortfalls are not dubious. Only if one cannot discern whether something looks or sounds better is anything dubious.
  
  The good thing about cPlay, as I understand it, is that upsampling is an option that can be bypassed. You may find that your DAC has better playback at 24/96 than 16/44.1 or 24/192. You may also find that software upsampling is superior to hardware upsampling and perhaps you prefer software upsampling with a NOS DAC or no resampling with a NOS DAC. On the other hand do you really want to resample in both software and hardware and does it sound better?
  
  It always seems to come back to implementation is everything.
- Analogy should be like this - cics 00:21:59 05/31/09 (0)
  Take a low-res pic which would be our 44.1k. Then take a hi-res pic (@ ~4x) to be our 192k version. Yes the upsampled results are as per the hi-res picture if strict bandlimited interpolation is done (SRC does this; I'm not able to verify SoX but their site suggests so).
  
  At issue with the upsampled hi-res pic would be added artefacts ("ringing" or more correctly "Gibbs phenomenon"). New information is added wherever we go from low to high intensity (i.e. discontinuities). This means at these boundaries the low intensity area now contains information that's NOT visible to us. This would be in the UltraViolet (UV) spectrum. Aside: Radio, TV, Microwave & Infrared are lower down the spectrum to visible light. Beyond UV are harmful X-rays and Gamma-rays.
  
  So does this invisible artefact affect the visual? Experimentation with SoX confirms this to be true. SRC offers no settings but has a redeeming feature in that the pre-ringing (same for post-ringing) is just ~0.3ms in duration. SoX offers settings that reduce the pre-ringing but at the expense of changing some aspects of the visual (phase shift). Although the pre-ringing is short, the levels are relatively high (some 36db lower than transient peak) bringing into question how well your speaker's tweeter can handle this ultra-sonic load. Should this be at or near the break-up or resonance frequency, your tweeter is most likely to loose the plot...
- RE: the dubious pleasures of resampling - Dawnrazor 22:39:34 05/30/09 (4)
  Hey serge,
  
  Forgive my ignorance, but I thought all this depends on the dac. Some handle different rates better dont they?
  - RE: the dubious pleasures of resampling - steppe 03:05:49 05/31/09 (3)
    Hello! Yes, I think that generally resampling takes place within dac but not in case of cMp-cPlay, I believe, where it is done by src or sox and then fed to the dac to be used for conversion unaltered. The process for resampling can be different depending on the math. In graphics, which, I repeat, is very similiar to wave, the math can be bicubic, bilinear and some others, also different dithering (even the terms are the same) processes are involved like bayer, fatting, floyd-steinberg math, diffusion, dispersion... Next, if I remember correctly, some DAC manufacturers employ tracing - the process that converts our wave into scaleable peak which is closest to analogue (according to their decision and or understanding). IMHO one of the best but hardest ways to achieve the best sound is to try to read and convert to analog every bit to the last one, but I am not an engineer nor am I a program developer, so I may be mistaken, but resampling does NOTHING to bring us closer to truth. I will prepare more pictures with dithering and vectorization (bezier) examples, used in graphics that closely resemble what is happening to the wav within the dac or resampling program (if it is interesting). Also, once again I want to say that I am not trying to discourage anybody from resampling, nor am I ungratefull or trying to say that Sics is doing something wrong.
    Serge.
    - The TRUTH? - DHT 4 ME 06:15:25 05/31/09 (2)
      what the heck does that have to do with anything. You are listening to a live event through speakers , in a different room, with different amplification, at different volume, at a different distance, with different cabling, in digital, with different DAC"s, and different computer chips, different versions of cPlay (or other players), oversampling DAC's....etc.
      It's a friggin representation of an event.
      You should know that with your photographic endeavors. Fidelity is a goal but it is more than pure specifications.
      
      If every system sounds different what is TRUTH?
      
      Now remember that I am sensitive to this being a professional photographer. I hear comments like "is that the way it really looked?" all the time. I try to explain that the slide film I use responds differently than the eye to a scene and the Ilfochrome has it's own character which is dependent on the illumination etc etc. Even the most accurate photograph is a representation and fine art is an "Artist's" representation.
      
      So everything is but a representation and higher bit depth and sampling rates are the way of the futuure. Right now the playback hardware is ahead of the media. Non oversampling DAC's will probably never be made again in light of HD audio. So we live with it and find better ways.
      Bob
      www.PlateauLight.com
      - RE: The TRUTH? - Dawnrazor 21:50:42 06/01/09 (0)
        
        In Reply to: RE: The TRUTH? posted by DHT 4 ME on May 31, 2009 at 06:15:25
        
        D,
        
        I try to explain that the slide film I use responds differently than the eye to a scene and the Ilfochrome has it's own character which is dependent on the illumination etc etc.
        
        I think that is what I was getting at. I thought some dacs like getting info at say 24/96 while others might be better off at 24/192.
      - RE: The TRUTH? - steppe 08:10:58 05/31/09 (0)
        
        In Reply to: RE: The TRUTH? posted by DHT 4 ME on May 31, 2009 at 06:15:25
        
        I mean the initial wav file. Nothing more.
        Serge
- Photoshop analogy - DHT 4 ME 16:34:33 05/30/09 (1)
  I am a graphics pro also.I agree with your assessment however I combat the fuzzy uprezzing by grossly over rezzing and then downsampling.
  It is the equivalent of sampling to 352.8 then do a DC offset and downsample to 192.
  Of course this is in Photoshop and I have no way of doing it for audio.
  Just and interesting idea
  Bob
  www.PlateauLight.com
  - RE: Photoshop analogy - kalimasada 21:22:15 05/30/09 (0)
    Yep, I agree, by upsampling to 400% and then viewing the result in 25% image size, Serge has in fact do two resampling processes. I can usually accept images downsampled using Photoshop internal function, but for upsampling I prefer it done with external plugin such as Genuine Fractal Print Pro. I prefer editing wave file with Wavelab software, but for upsampling, I prefer SRC.
    
    Sopian
- RE: the dubious pleasures of resampling - theob 13:42:34 05/30/09 (2)
  yes I agree upsampling de-focuses the sound just like it does in the picture. but I recall what j gordon holt said when somebody told him that solid state devices sound more accurate than tubes to which he said then I like tubes better than accuracy. I go through periods where I like 16/44 better than 24/192. Its all an illusion.
  - ILLUSION was the important word - rickmcinnis@dogwoodfabrics.com 09:34:50 05/31/09 (0)
    My schoolboy's limited understanding of the vastness of Hindu culture, I do wish I could take the time to truly understand, but the Hindu concept of ILLUSION is one of the most important concepts in coming to "understand" the world.
    
    All is illusion and one makes of it what they will. This hobby is about illusions within an illusion, no one knows what is really TRUTH, it is illusive and its discovery will do no one any good, or harm for that matter, for it is meaningless. Especially in this context.
    
    We try to find something that allows our consciousness to experience an event, an event we most likely did not attend in a hall we most likely have never entered, through microphones and recording equipment we will never own, blah, blah, blah.
    
    I think steppe had a clever insight, but not clever enough. I know there is no "bad" intention on his part, it was interesting, just not very useful. DHT for ME's analogy was far more accurate, to my mind.
    
    This is an interesting discussion but it leads nowhere. With such bare bones as RED BOOK we have to find a way to fill in the blanks and a best version of the "blank filler" will come. Just as with the LP, no one heard what we are able to hear now with LPs at the beginning of digital era, some amazing refinement occurred after what was the end of the LP's commercial life. Who knows what will happen with the CD, but all of us have lots of them and we would like to hear what is on them as best we can, as it was for those with large LP collections twenty years ago.
    
    My fear is that the future, except for a few specialist exceptions, is moving towards even less information, not more. In ten years we might be pining for the CD to return. I would bet someone will find a way to upsample/extrapolate this information into something much better than we would have ever thought possible.
    
    Bye,
    
    Rick McInnis
  - You have found the right word - steppe 14:16:28 05/30/09 (0)
    Hello, Theo! You have found exactly the right word - de-focuses, it softens, washes away the edge. Unfortunately I cannot post a bigger image - or tiff image, where everything is much more explicite - it won't fit on the screen here. Also an old CRT display (which I cherish) is much better at such subtle differences. If we zoom to highier percentages the "96 kHz" right side picture looks awfully washed-out.
    I personally prefer no resampling .
    Serge.
SoX online upsampler vs Izotope offline upsampler - appleteapot 17:59:54 05/29/09 (3)
I just compare SoX VHQ Linear 99 vs Izotope, 44.1 -> 192, and I feel that SOX online upsample is better than Izotope offline upsample. SoX has lower distortion and background is quieter. So I get a better imaging and resolution is higher. I use Lynx aes16e-> Mytek 8x192-> Beyer 990. Result is the same when I switch to Chord+MUBE.

My perception has always been that online upsample cannot beat offline... so I will try a more days. If SOX is confirmed successful then I can delete all the 192 up-sampled wave files (300MB+ each). SoX is not a CPU hog. My E7200 runs SoX without pops and clicks at 800Mhz (Asus P5KPL-CM) and heat sink is cold as room temperature.

Otherwise b26 sounds just as musical as previous versions. I guess this is the result of good ASIO integration.

Gee I thought B25 could not be improved!
- SoX online vs SoX offline - cics 10:27:21 06/01/09 (0)
  Just received an email from a cMP² user on a similar experience as yours, i.e. Online betters Offline.
- RE: SoX online upsampler vs Izotope offline upsampler - artcheng@netvigator.com 18:27:06 05/29/09 (1)
  Which filter do you use with Isotope?
  - RE: SoX online upsampler vs Izotope offline upsampler - appleteapot 19:02:19 05/29/09 (0)
    Sorry ackcheng I need to tell you later... My main PC just doesn't boot anymore after I insert the E7400 :( I need to fix it...
RE: cPlay 2.0b26 Released - ob2 00:59:04 05/29/09 (3)
With SOX, how the sample rate conversion is performed?

Is it done on the fly?
Or is it first complete the conversion and then play?

I think it may sound better if it is first converted to the target sampling rate before it is loaded to the memory and play.

Thank you.
- SoX resampling is done in realtime (and not during RAM load) - cics 09:57:29 05/29/09 (0)
  Given that there's less RAM processing with realtime upsampling, it would be better. It would be interesting to compare batch converted SoX file vs realtime upsampling.
- RE: cPlay 2.0b26 Released - ob2 01:02:10 05/29/09 (1)
  How good is SOX? How SOX compare to leading sample rate conversion software such as SARACON by Weiss if I use it to upsample from 44.1kHz to 96kHz?
  - RE: cPlay 2.0b26 Released - artcheng@netvigator.coma 04:57:34 05/29/09 (0)
    The SNR is one of the best. SARACON uses linear phase filter which SOX allows. If you look at the comparison site, SARACON is not that good afterall
cics, which is your favorite version of #26? - rickmcinnis@dogwoodfabrics.com 11:13:28 05/28/09 (30)
Being a lazy man who does not much want to find out for myself; I follow the leader.

I hope this is the one that will keep me from wearing out my cartridge!

Thanks,

Rick McInnis
- RE: cics, which is your favorite version of #26? - cics 10:14:37 05/29/09 (29)
  For starters, I would remove the preamp altogether (maybe give that cartridge a well deserved rest).
  
  I've settled with B26 SSE4 B9 with large buffer setting (E7xx processors have 3MB L2 cache - think of this as a free resource so exploit it). I use a single Kingston 256MB ValueRAM set at 3-3-3-5.
  
  SoX is very good and certainly has the upper hand with transient performance. On some recordings / genres it may be preferred. SRC offers better tonal decay and does a marvelous job of preserving those delicate harmonics. Overall SRC (@145db SNR) is no slouch on transients but its harmonic purity makes it a perfect choice for long term listening. It's like tubes without the haze.
  - I hope this is possible - rickmcinnis@dogwoodfabrics.com 12:28:02 05/29/09 (1)
    Nothing would make me happier than to not have to depend on the tweaky turntable and cartridge!!!
    
    Nothing like a click of the mouse and then music is presented.
    
    I am looking forward to hearing if that CD ripping software makes an audible difference.
    
    I have yet to install #26 so I am confused about some of what you said. I guess one can go back and forth between the SoX and SRC and make a choice? All of this is attractive even though I will look forward to their being a unified, this is best, configuration. At the same time I will take delivery of an absolute best phono cartridge!!!
    
    I admit, I am lazy, though once one finds a way to optimize you are compelled to use it. At one time I wanted to believe polarity control was ridiculous, until I learned to hear it.
    
    Have you implemented some of the power supply options the faithful have offered? Still using the onboard DAC of the JULI@ or back to the AERO CAPITOLE?
    
    If I was a cat I would be dead.
    
    Thanks!
    
    Rick McInnis
    - RE: I hope this is possible - cics 10:53:20 06/01/09 (0)
      To clarify, I prefer SRC@145db - harmonics & tonal decay is superior to SoX. If I use SoX then I set it to intermediate:30, bw 96% & no alias. Other settings are also good like minimum, bw 97% and alias.
      
      Setup still the same (Scarlatti DAC used with 2 cMP²: RME / Toslink / 96k & Lynx / Dual AES / 192k. AA Prestige SE & Scarlatti Clock collecting dust).
      
      I use Juli@ for development & testing. It still offers best value for money but I wouldn't rely on it to better your TT (and new cartridge). Perhaps doing GStew's mods together with I2S feed to ESS Sabre's 9012 Stereo DAC will suffice. Clean and isolated power to Sabre's digital and analogue voltage inputs is a must.
  - RE: cics, which is your favorite version of #26? - theob 10:37:21 05/29/09 (26)
    interesting that you chose large buffer vs small (opposite of my choice). I'll try large. Is there any cpu load differences between large/small buffer? I have several resampled sox files I will listen to both at same parameters and post.
    - Forever destined to listen to 96khz or less - theob 13:58:43 05/29/09 (25)
      I got the loudest version of metallics ever today while listening to juli@ analogue outs. Who knows maybe I have a real ghost in my machine. I listened all day yesterday and only ocassionally got slight static-y sound when loading ram sometimes--not gross. It was not constant but when I rebooted the 'load static' went away for most of the day. Today the metallics completely obliterated the music. Had to reboot and it went away. I'm running cpu volts set @ .85 VOLtS (READS .800 VOLTS ON CPUZ), 157 host clock control. Maybe I'm at the limits of my machine. Really thought I was going to be ok with sox. The gross metallics started when I tried to go to a prior track during cplay playback. BTW when I compared pre prepared 192 sox files with realtime sox upsampling in cplay the sonic results were almost identical. could not specify a preference. Cpu usage never went above 28% while running sox 192. I can't understand why this monster defect keeps coming back.
      - Lets try these tests - cics 11:20:40 05/30/09 (9)
        
        In Reply to: RE: Forever destined to listen to 96khz or less posted by theob on May 29, 2009 at 13:58:43
        
        The first test involves increasing Juli@'s latency to a maximum 128 samples (that's the maximum I would recommend for 192k output). I suspect you have tested this and got metallics.
        
        Second test is to never jump directly to a track, instead hit Next till desired track.
        
        I want to use Juli@'s I2S output to ESS Sabre's 9012 Stereo DAC (133db SNR) but this problem bugs me.
        
        3rd update on tests - theob 11:39:29 06/10/09 (0)
        
        In Reply to: RE: Lets try these tests posted by cics on May 30, 2009 at 11:20:40
        
        Did not like 128 latency but I have settled on 64. Sounds good plus I seem to be having fewer metallics as my linear ps on p4 settles in. Also I'm running sox at 192 with alias box checked. This means no filtering of aliases right? If right that means lower cpu load.
        
        2nd update on tests - theob 06:21:38 06/04/09 (0)
        
        In Reply to: RE: Lets try these tests posted by cics on May 30, 2009 at 11:20:40
        
        I have tried no mouse navigation within a file and for 2 days or so I've gotten 1-2 metallics a day--not bad. Now I will try 128 latency with the juli@ control panel (in past I've preferred 48 sonically) but I assume this reduces cpu load.
        btw sox upsampling within cplay is better (by a small margin sonically) and infinitely better for parameter setting and disk file usage. I've just saved 15 gigs of hd!
        so thanks again for a great cplay 2.0vs 26 release!
        
        Edits: 06/04/09
        
        update on tests - theob 05:14:58 06/02/09 (0)
        
        In Reply to: RE: Lets try these tests posted by cics on May 30, 2009 at 11:20:40
        
        I ended up setting cpu voltage higher (.896 on cpuz) and host clock control to 153 and it seems to be better (soundwise and metallics wise). Thank you ray konkle for this suggestion.
        I got metallics a couple of times while trying to change tracks with the mouse (sorry I just forgot). And although I had to reboot it seems not as bad while running sox at 192.
        
        Also I implemented a Power One power supply (12 volts. 1.7 amps thank you sondale, mark, robert, ray and gstew) for the p4 and it sounds really good (I'm sure it has more breaking in to do) but it also seems more metallic resistant. I have to figure out where to put it now.
        
        But all in all I may be getting a Lynx 2b. Hate to abandon the juli@ but it is really a distraction to reboot all the time. If I can get less than one a day or so metallics I could live with the juli@. We'll see.
        
        RE: Lets try these tests - theob 05:10:23 05/31/09 (0)
        
        In Reply to: RE: Lets try these tests posted by cics on May 30, 2009 at 11:20:40
        
        I tried only the 'next' or 'previous' buttons or keyboard for navigating within a file all day yesterday and no got metallics (more below in response to Bertel). When I was actively working as an engineer doing problem solving we used the technique called 'Is/Is not' map. It simply was the listing of conditions that are associated with problem occurence or non problem occurence. With cplay version 2.0v18 I never got one experience of metallics ever-over maybe hundreds of hours of use. I went back to it several times just to listen to music during 'heavy metal' days and it never failed in this way. Yes cplay versions higher than 18 are way way better sonically but all were subject to metallics. Not trying to blame cplay or cmp this is just a statement of fact that may shed some light on what is happenning.
        In addition to only using keyboard for within file navigation I am currently @ 157 hcc (was 155 the day of the big metallics)--so far after 1.5 days ok.
        
        Edits: 05/31/09
        
        RE: Lets try these tests - Bertel 03:07:23 05/31/09 (3)
        
        In Reply to: RE: Lets try these tests posted by cics on May 30, 2009 at 11:20:40
        
        Cics,
        
        I can already comment on the second test:
        
        My version of the metallics occurs even when cplay just continues playing and moves to the next track - then (at random) metallics can occur or not. I restart the track, sometimes once more, sometimes again, rarely again, and sooner or later the track starts without metallics. I could discover no pattern whatsover yet to give me a hint on possible causes (other than the combination of latencies maybe).
        
        However, since I am currently focussed on getting the system optimized for Buffalo32s first, it isn't an issue for me for the time being, i feed it with 16/44.1 since it does upsampling anyway. Once that is running fine I'll try 24/192 and will report.
        
        Best,
        Robert
        
        RE: Lets try these tests - theob 04:35:57 05/31/09 (2)
        
        In Reply to: RE: Lets try these tests posted by Bertel on May 31, 2009 at 03:07:23
        
        you said '...My version of the metallics occurs even when cplay just continues playing and moves to the next track - then (at random) metallics can occur or not. I restart the track, sometimes once more, sometimes again, rarely again, and sooner or later the track starts without metallics. I could discover no pattern whatsover ...' --------- was very close to my experience before I went 2.5" hd, fanless cooling except ----when metallics were bad (real bad) only a reboot would make them go away. Now that I am into 2.5" hdd, fanless cpu cooling and using sox I get metallics much less frequently and I get the kind that are less than 'real bad' (except for other day). yesterday, with using only keyboard to navigate within a file I got none. Also with sox I have not yet gotten any at auto track changes or loads.
        
        Robert I found out that cpu voltage and speed settings affect my metallics. I am right now at .85 volts (as set in bios) and 157 host clock control. I'm sure your equivalent but very low settings may impact your metallics.
        
        what's very frustrating to me is I can hear more purity @ 150 hcc but I get the problem more frequently plus sometimes I get instabilities (system shuts down). So finding the sweet spot is perhaps different for all of us. One thing though I believe impacts metallics, is power supply purity. I am using the P4 Ryelands cap mod which is great sonically but I'm not sure it makes my sys more 'metallic' resistant. Others with linear external ps P4 feeds may want to comment how it may effect metallics. As I recall you use a linear ps for P4 so maybe it just depends on voltage/speed levels plus whether you use juli@ or not.
        
        one last thing I have a benchmark too but I like juli@ analogue out better. When using Lynx did I understand correctly that you can only go digital out with an AES cable? Is there no i2s out with Lynx?
        
        RE: Lets try these tests - Bertel 05:19:14 05/31/09 (1)
        
        In Reply to: RE: Lets try these tests posted by theob on May 31, 2009 at 04:35:57
        
        Theo,
        
        I am at 0.76785 (not sure about the last three digits, can't look it up since I am not at home today) and host clock at 150MHz, that's stable but lower values don't work (have to restart from BIOS). At that values everything was fine with Lynx AES-16.
        
        IMHO power supply purity does not help to cure the metallics - I am on pure battery power with well-sized caps (so I think) for P4 and P24 and got the metallics just the same as when I power everything with the Antec (I have tested that already). Maybe things are different when I power Juli@ externally as suggested by Alfred/sonics, will test in the next few days.
        
        However, my task for the next few weeks is to go from Juli@ via i2s to Buffalo32S and optimize power supply (and possibly also caps and resistors?) in that chain. Since Buffalo32S does upsampling I output 16/44.1. Once that is running fine, I will switch to 24/192 and 24/178 (thanks Jean) and see if the metallics are back and how stable and effortless Juli@ can perform. Will report.
        
        And yes, as far as I know you can only go out digital from Lynx with their breakout cable that provides you with an AES/XLR plug which I ran into the Benchmark DAC1, worked absolutely stable and reliable. I tried both to find any possible way to (i) go out i2s and (ii) power the AES16 externally, but failed with both (probably could find a way for (ii) but (i) is impossible AFAIK, Lynx techs have confirmed this). Otherwise I would happily stay with Lynx without any doubt.
        
        Cheers
        Robert
        
        RE: Lets try these tests - theob 05:29:19 05/31/09 (0)
        
        In Reply to: RE: Lets try these tests posted by Bertel on May 31, 2009 at 05:19:14
        
        thanks for info.
        
        RE: Lets try these tests - theob 12:02:05 05/30/09 (0)
        
        In Reply to: RE: Lets try these tests posted by cics on May 30, 2009 at 11:20:40
        
        Ok I am trying not to ever use my mouse again--using keyboard to navigate. I was planning on getting a buffalo32 also but I guess you're saying metallics might interupt that too. I will try juli@ latency at higher values than 48 and see what that does (I know 48 sounds best). does that help alleviate cpu load?
      - RE: Forever destined to listen to 96khz or less - Bertel 14:39:22 05/29/09 (14)
        
        In Reply to: RE: Forever destined to listen to 96khz or less posted by theob on May 29, 2009 at 13:58:43
        
        Theo,
        I'm afraid this doesn't really help to solve the issue, but I thought I'd just share:
        I am a late Juli@ convert, have been running my highly optimized system (at least so I believe) until last week with Lynx AES16. I left everything as it was (e.g. 256MB ValueRam, E7200 with CPU voltage at 0.76875 I believe, all optimizations done etc.), just took out the Lynx card, uninstalled the driver, plugged in Juli@ and installed the unified driver 1.05 - and instantly and for the first time I had the pleasure to get to know your metallics - it's dreadfull...
        Since I'm currently going Buffalo32S (which does resampling and reclocking, something I definitely don't like...) I went back to 16/44.1 and everything is fine. So this is just to say that a completely stable and (for me) close to perfect system tipped over just by exchanging Lynx with Juli@. I definitely have to have a Juli@, since Lynx can't do i2s and external power (and cics said its ASIO implementation is so fine), but I don't really have a doubt that it is either Juli@'s driver that screws up, or Juli@ hardware - now the latter was my theory before you said that you have the metallics even through Juli@'s analogue outs, I now expect to get them even over i2s, still to verify, if so it can't be the digital out part. Ah yes, and I had the idea of experimenting with PCI latency setting in BIOS, don't know if that could make a difference, haven't tried yet but could make sense.
        Just sharing another experience...
        Robert
        
        Edits: 05/29/09 05/29/09 05/29/09 05/29/09 05/29/09 05/29/09 05/30/09
        
        RE: Forever destined to listen to 96khz or less - theob 15:24:47 05/29/09 (13)
        
        In Reply to: RE: Forever destined to listen to 96khz or less posted by Bertel on May 29, 2009 at 14:39:22
        
        thanks Robert. Maybe the solution is the Lynx. I know its expensive but I bought power cords more costly. What is you theory about pci latency? Do you think something other than 128mb might impact it. Are you running a ssd hard drive? I am happy to hear you report it. If more people taslk about it the chances of a fix go up.
        
        RE: Forever destined to listen to 96khz or less - Bertel 15:42:58 05/29/09 (12)
        
        In Reply to: RE: Forever destined to listen to 96khz or less posted by theob on May 29, 2009 at 15:24:47
        
        Theo,
        Lynx is definitely a solution - if you can live with XLR output to say the Benchmark DAC1 (as I had before, that was good and so stable and absolutely hassle free) and do not fancy i2s (like I do now to feed the Buffalo32S). On the other hand, once you go Buffalo32s you only need 16/44.1 since it does upsampling and reclocking anyway, so there will not be a problem. I am intending though to build my own solution based on ESS 9018 chip later that year (8ch dual mono configuration) so I've got to find a solution to this, but fortunately that's still far enough away ;-)
        Well, my "blaming" PCI latency is in no way scientific or based on any facts yet, just a gut feeling - my metallics occur whenever I start a track (when cPlay set to SRC @ 145.68db and 192.0), it's either there or it isn't, or maybe it also starts with glitches or dropouts - I just have to restart the specific track, it either reoccurs or is gone, no pattern foreseeable. I'm just guessing, but looks to me as if processor's output and soundcard input are not in sync, and that as far as I understand it can only be driver or something "on the way", during transport, i.e. PCI and its latency I guess. As I said, just a gut feeling, haven't had the time (and need due to 16/44.1) yet to really check, one would need to simply try for some time with a setting other than 128. However, my metallic issue was definitely introduced with Juli@ and its driver, everything else has been there and unchanged before and has worked perfectly stable and without any glitches or dropouts or even any distortions noticable.
        And yes, I have a SSD only.
        Cheers
        Robert
        
        Edits: 06/03/09
        
        But does the BUFFALO chip upsample as well? - rickmcinnis@dogwoodfabrics.com 19:53:32 05/29/09 (10)
        
        In Reply to: RE: Forever destined to listen to 96khz or less posted by Bertel on May 29, 2009 at 15:42:58
        
        Seems unlikely to me.
        
        I know I have a DAC with the BURR BROWN upsampling chip and my set-up sounds MUCH better with the computer making the calculations.
        
        It seems implausible to me that any chip could do a better job than a powerful microprocessor and these very clever upsampling software choices.
        
        Have you tried it both ways?
        
        I had the metallic problem when using the computer after 8 weeks of being turned off and installing #25. After it settled in it never happened again. To be honest this was only over a two days period.
        
        After Theo has exchanged so many things I am seriously thinking it could be the mouse. Are you using the cics recommended LOGITECH? I had my temporary problem when making some quick mouse clicks (with the recommended device). Could a somewhat recalcitrant mouse send confusing commands to the computer creating this condition? I know I am making a stretch, but this has gone on so long there must be something less than obvious at work.
        
        Bye,
        
        Rick McInnis
        
        RE: But does the BUFFALO chip upsample as well? - theob 08:40:51 05/30/09 (3)
        
        In Reply to: RE: But does the BUFFALO chip upsample as well? posted by rickmcinnis@dogwoodfabrics.com on May 29, 2009 at 19:53:32
        
        I would have never thought a mouse could be a source of problems but I use a p/s2 type mechanical roller ball mouse with a 6 foot extension (to reach my listening chair). Is this a problem? If I could navigate the music library with my keyboard I'd get rid of the mouse.
        
        I know it sounds absurd, BUT ... - rickmcinnis@dogwoodfabrics.com 09:14:12 05/30/09 (2)
        
        In Reply to: RE: But does the BUFFALO chip upsample as well? posted by theob on May 30, 2009 at 08:40:51
        
        when I thought about how the problem was triggered in my set-up it isn't completely ridiculous. A baffling solution to a baffling problem?
        
        I would think you would find this easier to use:
        http://www.newegg.com/Product/Product.aspx?Item=N82E16826104080
        
        This is what cics uses (or did use when he recommended it to me). I have always tried to use what HE was using to assure I was getting the same end result. One would think a hardwired mouse would be less likely to misbehave, BUT at the same time you have this antenna in your room and no telling what could be happening.
        
        Even if it doesn't settle the problem it is a pleasure to use.
        
        I know you might be starting to think I work for NEWEGG as much stuff as I have told you to buy! My email address is not a ruse.
        
        I sincerely think this is something worth trying. After all you have tried EVERYTHING else. (If this works I think Stephen Jobs should give me a job at APPLE even though I hate their machines)
        
        Bye,
        
        Rick McInnis
        
        RE: I know it sounds absurd, BUT ... - theob 12:07:43 05/30/09 (1)
        
        In Reply to: RE: I know it sounds absurd, BUT ... posted by rickmcinnis@dogwoodfabrics.com on May 30, 2009 at 09:14:12
        
        always wanted to try it (but didn't you get this problem with the logitech?). Rick I cannot thank you enough for always trying to help to solve my problems.
        
        Edits: 05/30/09
        
        Only twice ... - rickmcinnis@dogwoodfabrics.com 09:39:27 05/31/09 (0)
        
        In Reply to: RE: I know it sounds absurd, BUT ... posted by theob on May 30, 2009 at 12:07:43
        
        and that was in the settling in stage after eight weeks of being turned off and then restart and install #25/disable EIST and trying to lower the processor voltage too quickly/
        
        After being on 24 housrs it did not happen again.
        
        And it was, each time, started by some fumbling with the mouse. Hitting multiple buttons quickly.
        
        At least you could get rid of that wire!!!
        
        Rick McInnis
        
        RE: But does the BUFFALO chip upsample as well? - Bertel 20:27:48 05/29/09 (5)
        
        In Reply to: RE: But does the BUFFALO chip upsample as well? posted by rickmcinnis@dogwoodfabrics.com on May 29, 2009 at 19:53:32
        
        Rick,
        yes, I've had this confirmed by the designers of the Buffalo32S, the oversampling FIR filter is also clearly mentioned in the data sheet (although they don't really disclose how the upsampling is done and to which frequency), the ESS9018 chip has what they call the Time Domain Jitter Eliminator which basically is upsampling and reclocking, as with your Burr Brown a technique that is commonly used. The ESS9018 is highly praised for exactly this feature, it is said to be very efficient and to do things very well, but I agree with you, I have yet to hear a solution where a hardware upsampler does a better job (or at least not worse) than a software upsampler like SRC or SoX.
        And yes, the chip is designed with the ability of turning this feature off, it requires setting a few registers via i2c, but the firmware used by the Buffalo32S designers does not offer that functionality, you need a custom firmware for that. Surely the Buffalos are a very fine piece of audio design and manufacture, but I believe the chip can do even better. Since like you I do not want the DAC to do the upsampling, plus I do not think that our cMP2 environment produces too much jitter anymore that needs attenuating (the measurements cics had done in March last year were already impressive, and so much improvements have been made since then), I will build my own DAC later this year with two ESS9018 chips in dual mono configuration (recommended by ESS for best audiophile performance) and compare - at least that's the plan ;-)
        Best,
        Robert
        
        Edits: 05/30/09 05/31/09
        
        RE: But does the BUFFALO chip upsample as well? - bidule 03:19:53 05/31/09 (3)
        
        In Reply to: RE: But does the BUFFALO chip upsample as well? posted by Bertel on May 29, 2009 at 20:27:48
        
        Robert,
        
        I'm planning same thing.
        
        I was reluctant to select Sabre unit over TI 1704 for the same exact reason you mentionned, ie internal upsampling / downsampling.
        This technique allows the widest compatibility with the different sampling rates sound format availlable (everything from 32k up to 192k)
        Although this is common practice in Silicon SRC and good to rmove jitter of common source, here we have a machine and a software that provide us with minimum jitter at the PCI Sound Card output which mean (if well implemented) at the DAC Input.
        I'm thinking for my dac implementation to try to achieve as low jitter as possible all the way down to the analog which means the use of a Master Clock close to the DAC chip.
        The problem here if one wants to avoid too much complexity implies to select a single as universal sampling rate (178K4 or 192K).
        Should you select 178k4 it would be perfect for original files sampled at 178K4 and close to perfect with 88k2 and 44k1 providing that you select the right settings in Sox (that i suspect may be full system dependant).
        So the question is what will be the standard sampling rates (if any) for Hi res files pick the right clock for that standard and accept imperfection for other sampling rates.
        Now that you explained us that Sabre can be forced not to use its internal SRC, it comes back to interrest to me because of its ability to work with 32 bits resolution.
        
        So, if you move on with this project and if we can share energy, you can count on me.
        
        Best,
        Jean
        
        RE: But does the BUFFALO chip upsample as well? - Bertel 03:41:45 05/31/09 (2)
        
        In Reply to: RE: But does the BUFFALO chip upsample as well? posted by bidule on May 31, 2009 at 03:19:53
        
        Jean,
        absolutely great to hear you're heading down the same path - or rather up :-)
        Exactly, the first assumption I'm making is that we in our cMP2 environment have eliminated or reduced jitter to such an extent that the downside of on-chip jitter reduction techniques, e.g. hardware upsampling and reclocking, more or less clearly outweigh the benefits of doing the upsampling in software and closely coupling the DAC via i2s - in my expectation this is superior, but we'll have to test and see. IMHO the ESS9018 is currently the best DAC chip around, but need to properly re-evaluate.
        Secondly, I'm also with you that it is key to use the best master clock available on the DAC. As far as I can see, that is NewClassD's Neutron Star (http://www.newclassd.com/index.php?page=36), Lars has done an outstanding job with this.
        Thirdly, the question of selecting one "standard" sampling rate for everything and optimizing for this is easy for me I thought - since all of my playback is through cPlay, I intended to use 24/192 (or rather its 32bit incarnation through ASIO2) through SRC or SoX exclusively. Your comment on 176k4 though suggests that this probably might be the best choice (another assumption I make for me is that most important for me is data derived from red Book CDs, thus 16/44.1, that's what I focus on), probably wil go for that, need to get more info on this, and then choose clock and settings etc. accordingly.
        And lastly but most important for me, I'll be absolutely glad to sync with you and join forces once I get started with this part of the project - look forward to this very much! Please PM me (if possible) so I have your coordinates.
        Best,
        Robert
        
        Edits: 05/31/09 05/31/09
        
        RE: But does the BUFFALO chip upsample as well? - bidule 04:34:05 05/31/09 (1)
        
        In Reply to: RE: But does the BUFFALO chip upsample as well? posted by Bertel on May 31, 2009 at 03:41:45
        
        Hi Robert,
        
        Glad to hear from you.
        I've selected 176k4 as the best for CD material for the exact same reason mentionned earlier.
        Up to now i could only test on my reference system (i'm hifi dealer) with 44k1 and 88k2, to be honest i didn't even try 96k.
        But i suspect that upcoming hi res material will be 192k ...
        
        Reagarding clock i was also interrested in Audiocom stuff. Also praised as the best one in town.
        
        The next important thing is power supply and IV conversion.
        
        I will be playng soon with different PSU for evaluation.
        
        My problem with Sabre is how to get it, as i don't want to use Buffalo, buffalo one not any more availlable and at least no more support, buffalo two is too expensive if you take into account that i consider changing IV and PSU. Second big problem Board design.
        
        That's why i am on the conservative approach thinking to use TI 1704.
        
        Best regards,
        Jean
        
        RE: But does the BUFFALO chip upsample as well? - Bertel 05:56:46 05/31/09 (0)
        
        In Reply to: RE: But does the BUFFALO chip upsample as well? posted by bidule on May 31, 2009 at 04:34:05
        
        Jean,
        you're probably right that over time there might be a shift to 192kHz material - for the time being for me this still is almost irrelevant since by far most of my music ("old" one I have as well as "new" one I buy) is 16/44.1 because it comes on CD. Let's see how SRC vs SoX as part of cPlay develop, I'd very much be interested in cics' opinion on what sample rate he sees best for Red Book material (176 vs 192) and for what reason (SNR? etc.)
        Audiocom is certainly good - need to ask Lars why he's better :-) My knowledge in clock technology and architecture needs to be expanded and updated before I will decide on which to choose.
        Well, power supply - you certainly have seen that I fancy battery plus proper capacitance - can only recommend that, need some extremist spirit though ;-)
        Buffalo32S IMHO is not expensive at USD 469 at all, given the top-of-the-hill solution you get with it. I'm currently setting it up as my reference, then quite likely will go with 2 x ESS9018 evaluation boards as a next step (not a bargain at 2 x > EUR900), and then take the experience of those two to get to some "final end-all-search" DAC, who knows ;-)
        Cheers
        Robert
        
        Edits: 05/31/09 05/31/09
        
        Very good! You are quite enterprising! - rickmcinnis@dogwoodfabrics.com 09:03:42 05/30/09 (0)
        
        In Reply to: RE: But does the BUFFALO chip upsample as well? posted by Bertel on May 29, 2009 at 20:27:48
        
        I know we will all look forward to your implementation.
        
        Bye,
        
        Rick McInnis
        
        RE: Forever destined to listen to 96khz or less - theob 17:15:13 05/29/09 (0)
        
        In Reply to: RE: Forever destined to listen to 96khz or less posted by Bertel on May 29, 2009 at 15:42:58
        
        thanks for your response. I'll try different pci latency values.
RE: cPlay 2.0b26 Released - theob 04:54:44 05/28/09 (0)
very nice, the ability to swap sox parameters on the fly is very usefull for finding a 'personalized sonic sweet spot'. I still prefer M for phase but am now experimenting with bandwidth. Seems like allowing aliasing is a no brainer (for me anyway). I don't have a handle yet on overall sonics (but very very close to 25) so far.

Excellent release! I like it!
RE: cPlay 2.0b26 Released - artcheng@netvigator.com 03:59:42 05/28/09 (3)
There is an interesteing article on SRC and filters here. The author compared minimal phase, mixed phase and linear phase filters

http://tech.groups.yahoo.com/group/acourate/files/Uli/
- RE: cPlay 2.0b26 Released - theob 08:40:34 05/28/09 (0)
  I got it finally
- RE: cPlay 2.0b26 Released - theob 05:06:13 05/28/09 (1)
  can't sign on to link can you copy / paste here?
  - RE: cPlay 2.0b26 Released - artcheng@netvigator.com 06:46:32 05/28/09 (0)
    I am not sure how to post the white paper as it is a pdf and is quite large. If you send me your email, i can post it to you

Post a Followup:

FAQ

Post a Message!

Forgot Password?

Moniker (Username):
Password (Optional):
	Remember my Moniker & Password (What's this?) Eat Me
E-Mail (Optional):
Subject:

Message:	(Posts are subject to Content Rules)

Optional Link URL:
Optional Link Title:
Optional Image URL:
Upload Image:
E-mail Replies:	Automagically notify you when someone responds.

To view your new posting or follow-up, click on the RELOAD or REFRESH button on your browser.