|
Home
/ FAQ
/ News Classifieds / Events |
Audio Asylum Thread Printer |
Get a view of an entire thread on one page |
41.183.0.21
In Reply to: RE: cics, which is your favorite version of #26? posted by rickmcinnis@dogwoodfabrics.com on May 28, 2009 at 11:13:28
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.
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
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.
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.
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.
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.
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.
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
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.
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
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
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?
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
thanks for info.
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?
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
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.
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
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
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.
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
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
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
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
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
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
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
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
I know we will all look forward to your implementation.
Bye,
Rick McInnis
thanks for your response. I'll try different pci latency values.
Post a Followup:
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2009, Audio Asylum, all rights reserved ]
[ Go Green ]
[ Take5 ]