 
|
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 |
68.43.175.248
In Reply to: RE: In cPlay, select Julia@'s analogue outputs (be careful with volume). nt posted by cics on March 22, 2009 at 05:18:49
ok got it to work. It sounds fine. What should I look for?
Follow Ups:
playing for 1 hour or more @ 192-- no problem. This is certainly feasible also going through my Benchmark but rare. But if its not in the pc system where do you think it could be? In the digital cable or dac? Doesn't make sense to me if a reboot fixes it.
...and only report if I get an issue
I'm not saying I found the issue but it sure seems a possibility now. I'm listening to my dac through a different digital cable---a toslink glass. I'm running 192 but I assume juli@ reduces this to 96.But is the theory that either my other digital cable or my dac was corrupting the signal?
Edits: 03/22/09
5 minutes listening to cplay @192 through toslink to my dac there it was, the dreaded metallics, and w/o rebooting I switched over to headphones---no problem through the juli@ analogue out. Once again I could not get digital out to my Benchmark to work w/o rebooting.What does this mean? I can't believe my Benchmark is not functioning. I'm really confused on this.
Edits: 03/23/09
Following are somethoughts as to what is the root cause of my 'metallic issue'.1) Its pure and simple the dac (a USB Benchmark).
Pros: I can make it go metallic through 2 digital cables while the
analogue out of the juli@ sails along with no issues @ 192/146.
Remember I can go metallic on the digital out of juli@(running 192/146)
and then w/o rebooting switch over to analogue out and no issue.Cons: the metallics go away with reboot; use of fd for music files @
192/146 results in no issue; other cmp/cplay users use Benchmark-- they
have reported no issues like mine2) Its the juli@ drivers that get corrupted
Pros: goes away with reboot, juli@ analogue out does not require drivers
(its all hooked up with hardware on the card)Cons: Use of fd for music files ok @ 192/146
3) If 2 is true what causes drivers to go corrupt? Could be the processor
which could be what we used to call 'a minus 3 sigma' processor. That
is a processor that is way on the low side of the performance spectrum.
Pros: Explains why higher loaded cpu precipitates problemCons: Reboot solves issue for awhile
I guess my next step is to try a dac with 192 capability other than the Benchmark.Anybody have ideas? I don't want to buy a new dac (costly) or a new soundcard (costly to go Lynx). Buying a new cpu is not too bad $ wise but don't want to do if this not root cause.
Edits: 03/23/09 03/23/09
I wanted the analogue output test to verify this: Benchmark DAC1 experiences a re-sync when selecting another track or album but this seems to cause a DSP bug (which converts 192k to 110k). When doing a reboot, DAC does a "fresh" sync. In all other cases, DSP is upsampling to 110k - only when input is 176k or 192k, downsampling occurs.
FD is always "online" whilst HDD goes from idle to read state causing the system to pause hence why a resync is needed at DAC).
Can you test Juli@'s analogue outs to Amps? Either RCA or TRS (Balanced) can be used.
Also see this discussion for latest BIOS & Devices setup (in your case, host freq of 160 is safe but 150 is optimum). I'll update the usual revision post in cPlay once I'm happy with stability.
It sounds very very good. I'm not sure how it compares to Dac1 yet, my initial impression is that its not as good. But I'll listen for awhile and make a final judgement later. Oh heck the analogue part of the card is not even broken in. The final assessment will take several days.Initially very very surprisingly good though.
Edits: 03/26/09
ok I'm going to have to run this way after I send my dac back to Benchmark. I'm going to have to get some interconnect adapters so it may take a day or so. But yes I will do it.
They indicate that through the spdif input the Benchmark is asynchronous and so the likely cause of my issue is not the Dac 1 losing sync. So to test that theory I've hooked up my oppo (which outputs 24/192) out of specially modded rca outs on the back panel. I bought it so I could listen to single layer sacd's.
I'm currently running a 24/192 source(IRobot on Classic HDAD--one side 24/192lpcm and one side 24/96 dvd) through the Benchmark to see if I get the 'metallics'. If I get the issue all agree that its the dac. If I don't, Benchmark believes its the digital stream coming out of the juli@.
When I ran the juli@ analogue outs sunday and compared to Dac 1, the Dac1 was connected via toslink to the Benchmark. But, for normal listening I usually run spdif out directly to the dac1 all the time because it sounds better that way.
We'll see.
At any rate Benchmark offered to bench test my dac to make sure its within spec.
I'll let it go 7 hours (which was how long I ran juli@ analogue out). But if this turns out not a problem I'm thinking it could be the cpu or mobo.
Cics would you agree with this assessment?
I want to understand true root cause so I can fix it.
Mobo and CPU are OK.
You have a sequence of actions that causes the problem. This time do same but before playing next track or album (i.e. before switching from stop / pause to play), switch inputs back & forth on DAC1, e.g. Toslink and then back to BNC (assuming this is the input being used). The idea is to force the DAC1 to do a sync. Start play - do you get the problem? If yes then its the SPDIF output on Juli@ otherwise its a DAC1 issue.
Let me make sure I understand what you are saying:
Put cplay on pause or stop, toggle the Benchmark full cycle back to bnc. Play cplay. Ok I can do that. But why do you say that if it goes metallic its the juli@ stream, if not its the Benchmark? Don't understand that logic.
Oppo went 8 hours with no problemsTried recycling or toggling input switch on dac & cannot precipitate issue. But I can't understand the logic of this test. I can sometimes go anywhere from 5 -30 minutes before I get issue on normal listening. I only toggle within a 5 second interval.
I'm noticing when I get the issue is usually right at point where I believe cplay is switching off/on to get more data from hdd (right around the 2:00 minute mark) or at the beginning of a new track.
Edits: 03/25/09
Got further input from Benchmark
However, try his test anyway, so that we may rule out the DAC1. When the metallic sound is there, try switching inputs. Try power cycling the DAC1 (remove the power cord). Try unplugging the cable from the DAC1’s digital input and then re-plugging the cable. If any of these causes the problem to go away, then the DAC1 may be the culprit. Otherwise, the problem is with the digital outputs on your card.
Tried them all & it didn't make issue go away.
Cics do you agree with above? Tried your test which suggests dac and Benchmark's test which suggests its the juli@ digital stream..
Could be a design fault which means buying a new Juli@ won't solve it. Doing I2S out could work as this is what we tested with analogue outs & headphones.
I can confirm another juli@ won't fix (tried it and got same problem). Do you know of anybody else that has this issue? Reason I ask is maybe its an interaction. Maybe a better processor will fix. When the 35 nm processors come out I'll try as long as they are compatible with the Gigabyte mobo.Again thanks for all your help. Even though I don't have a clean solution I do have several workarounds. Listening to juli@ analogue outs, while not fully broken, is a delight. Perhaps not as extended nor dynamic as Benchmark, juli@ analogueout is very sweet/delicate. Once broken in I will lower host clock control to 150.
Edits: 03/26/09
See latest in cPlay's update post for BIOS and device changes. Juli@ analogue out should improve.
Question: Are you using laptop HDD (2.5") or standard desktop ones (3.5")?
I have a std 3.5". what would a 2.5" do for me? btw juli@ analogue out is very good. Still not as extended (highs and lows), not as dynamic, not as big spatially (esp depth) as Benchmark Dac1. But (and a big but) juli@ analogue out is sweeter than Benchmark. I could listen either way. One particular spec that may be contributing to this: Juli@ analogue out output impedance is 100 ohms, Benchmark is 0.1 ohms.
Edits: 03/28/09
Well I'm still on the problem and if you're powering your standard HDD from GD that could be the cause due to too much load. Standard drives consume much more power than laptop drives.
Great feedback on the analogue outs - yes they're different but can you make a call on which you prefer?
Right now I have to say the juli@ only because I don't get the problem. If the problem could be fixed I would have to go back and forth to make a definitive call.
Are there any alternatives to the gd power supllies with more capacity?
Btw the new bios specs are great, very very good midrange and sound is very coherent top to bottom, best yet.
Have you tested hvavandepas recommendations? Seems like they may be worthwhile? See link
Funny though my pc reset Host Clock control to Auto as well as system memory multiplier and Dram timing selectable on bootup. So its not optimum sonically. But we'll see if the metallics go away (I rebooted to get host clock control to 160 everything else to latest spec).
,
I really believe it is power related: always seem to be more frequent metallics when power line is noisy(noisy today good time to test). Also after I tried internal sata power feed I put back the gd and tried a different power cord to pc (still running juli analogue outs) listened for a while then rehooked up the Dac1 and it was metallic right from the start. Switched back to juli@ and I started noticing a 'beginning of the metallics'---lots of static---when I switched tracks not always but sometimes. But if I just indexed cplay to next track then back again to previus track it would go away. So, I don't know, I'm starting to think maybe power and/or cpu load related might be the issue.
Why are you convinced its not the cpu?
I'm liking it very much (maybe after 3-4 days its broken in now). Even though the shortcomings I mentioned vs Dac1 are still there, at 150 host clock control, eist disabled, new devices disabled I am starting to think I like it better. Even with the small ground loop I'm getting, I just love the highs, midrange. While the bass is not as tight (as Dac1) its plumpy in a graceful, musical way. Dynamics perhaps not as good but still better than anything I have heard (save dac1 via cplay/cmp).Many music files that were hard. borderline unlistenable through the dac1 are now much better.
Edits: 03/28/09
Here is Windows Task Manager data(just to see if anything here is amiss):cpu usage: 44%-64%
Handles: 1162
threads: 120
processes: 14Physical memory: 251k
available: 74K
sys cache: 91kcommit charge:
total: 164k
limit: 239k
peak: 164kkernel memory:
tot: 8k
paged: 6k
nonpaged: 3KAnything pop as out of the ordinary?
I am running 192/146, at 150 host clock control all else per latest spec.Also since I lowered host clock control I noticed cpu usage go up and my metallics come more often than before (while listening to dac1). Also I notice when I reboot the pc is re-setting host clock control to auto , multiplier to auto and dram timing to auto.
Since I suspect my root cause may be power related I tried plugging my audio pc, power line conditioner(Hydra) into a different outlet--> however I got the same result: the metallics after 5 minutes of play time.
Also since posting the above I noticed some services wer still started so after I closed all (except the 2) I get 997 handles; 100 threads; 13 processes while running cmp/cplay. Cpu peak usage still about the same as above.
Edits: 03/29/09 03/29/09
During playback, you should only have 12 processes. Check that you only have the 2 required services running (often Crytographic Services starts when doing thing in device manager and must be manually stopped).
If not stable at 150, then try 160 or 165.
Problem appears to be power related because you can't create it when using FD. Standard HDD causes a significant power spike (and associated ground noise) when transitioning from idle to sequential read. Using main PSU doesn't help either!
I was hoping you were doing the test with a laptop drive - any chances of this?
gotta buy one so unless absolutely necessary I won't (just bought a new hdd). If you feel I should I will though. you mean just for music files right? I won't have to reload windows again to set up a new os partition, I hope.
I have 13 processes while running: cicsplay; cicsremote;cmp; juliapan; svchost; lsass;services; winlogon (aka minlogon);crss; smss; system;system idle process. Which one is un-necessary?
Edits: 03/29/09 03/29/09
Tried running cplay (w/o cmp engaged) off of fd and it went metallic right away. Tried running off of fd with cmp engaged and 1st time it stuttered (had to reboot). After reboot it started but went metallic right away.My conclusion is that at 160 hcc and eist disabled I'm getting the problem even on fd. Cpu related?
I upped clock back up to 165.
Edits: 03/30/09
had to bump up hcc to 175 to avoid anomalies: stuttering, noise (static-y almost like a metallic overlay but goes away by re-indexing)
Edits: 03/31/09
after I implemented nopae and checked services each time I reboot to get back to only 2 services. I have to say the sound is very, very good. Cics yes this is a great foundation to build on.The mids, highs are absolutely best I have heard in my sys. If I lost any soundstage, bass to the dac1 I pick it back up with nopae.
While I love the sound I'm bordering on instability. I get the fuzzies almost metallics when cplay swithches tracks or reloads in a track. But I re-index it manually and its ok. I hate to keep asking but doesn't it sound like borderline processor performance? I know you said it probably isn't but there's not much left in my pc to suspect as root cause of my issue. (Follow up: Running music files off flash drive fixes this noise issue for awhile, but had to go back up to 155 hcc.)
But bravo on new spec!!
As you can see I think my sys is right at the borderline of stability (or at least this crazy noise I now get in the juli@ analogue out mode).
Edits: 04/01/09 04/01/09 04/01/09 04/01/09
... the tics, drop outs, metallics, fuzzies got so bad today I could not listen to cplay 20 so I loaded cplay 18 back in. Not a tic, drop out, no fuzzies, no anamolies.
Its interesting because I get about the same cpu usage as cplay 20 and 18 is not as good sonically but something about my machine does not allow cplay 20 to play w/o problems.
Does this make any sense to you?
bump
You are a gentleman and a scholar (in the literal not figurative sense). If I have to get another dac (that is if Benchmark can't fix mine) I will do so so I don't have give up on cplay/cmp.
Thanks again for a wonderful player.
I guess I will see if Benchmark will fix it. I'm wondering if others with Benchmarks experience this problem? I guess its time to get a Buffalo Sabre which has a way to input I2s.
Rickminnis: my apologies to you. You had suggested this before but I defended my beloved benchie.
I am also using a Benchmark DAC1 PRE. Yesterday I was listening, off and on, and suddenly I noticed something like an echo and distortion in the right channel.
I had just had the HDD out to copy the C:/ partition and thought I had not secured it properly. I shutdown, repositioned the HDD on the mounts and started up again. Everything was now ok.
Makes me wonder if what cics is saying applies to all Benchmarks???
They have excellent CS and will probably look into your problem Theo. Ask them to tell you what they find.
RayBan
Appreciate some input.
theob,
I am waiting for the new Buffalo - it seems to promise a lot - but no idea on the price just yet!
Alan
me too unless Benchmark can fix my dac
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 ]
