Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ammitsboel]

bblackwood wrote on Sun, 13 March 2005 19:20

What sort of DAC are you using, Henrik?

I'm using an Audio Note DAC 5.
It's a non oversampling type of DAC.

[ammitsboel]

Homero wrote on Sun, 13 March 2005 19:57

My chain is: M-Audio (internal sync) SPDIF out--->dCS 972 D/D (SRC UP-Sample)---->dCS 954 D/A----> analog processing...

Why do you upsample before the DAC?
Putting another device in the signal chain will always sound different... some more artificial than others.

Do you like this better because it sounds smoother or because it sounds more like the original material?

Best Regards

[Homero]

ammitsboel wrote on Sun, 13 March 2005 17:11

Homero wrote on Sun, 13 March 2005 19:57 My chain is: M-Audio (internal sync) SPDIF out--->dCS 972 D/D (SRC UP-Sample)---->dCS 954 D/A----> analog processing... Why do you upsample before the DAC? Putting another device in the signal chain will always sound different... some more artificial than others. Do you like this better because it sounds smoother or because it sounds more like the original material? Best Regards

I didn't like the sound when the card in internal clock was feeding the D/A directly, so I tried the upsample / re-clocking
After the upsample the sound is more alike the original, it retains better the spacial information of the original.
I think it is clock issue, I can not blindly trust the clock of that card

Best Regards

[ammitsboel]

Homero wrote on Sun, 13 March 2005 20:49

I didn't like the sound when the card in internal clock was feeding the D/A directly, so I tried the upsample / re-clocking After the upsample the sound is more alike the original, it retains better the spacial information of the original. I think it is clock issue, I can not blindly trust the clock of that card

It sounds very odd to me that a re-sampling would sound better than the original sample length?

[Homero]

ammitsboel wrote on Sun, 13 March 2005 18:29

Homero wrote on Sun, 13 March 2005 20:49 I didn't like the sound when the card in internal clock was feeding the D/A directly, so I tried the upsample / re-clocking After the upsample the sound is more alike the original, it retains better the spacial information of the original. I think it is clock issue, I can not blindly trust the clock of that card It sounds very odd to me that a re-sampling would sound better than the original sample length?

For me too, after all there is no new information added. But we have to consider the clock issue here. After the SRC there will be a new clock driving the D/A, unrelated with that output-ed by the card. So I think it's possible that with upsampler we can obtain (maybe not  always) a better reproduction of the original data.
It is not the same case when you do a SRC with some software like Barbabatch, there is no clock there.
In this case the upsampler and re-clocking processes are occurring in real time and you are converting to analog.

Best Regards

[bobkatz]

Homero wrote on Sun, 13 March 2005 14:57

I have a variation of the theme here. I have started to use a cheap M-Audio Firewire interface to speedy up some tasks related to SRC. That interface uses an ASIO driver and Digital Performer supports it. My chain is: M-Audio (internal sync) SPDIF out--->dCS 972 D/D (SRC UP-Sample)---->dCS 954 D/A----> analog processing... I believe that the dCS 972 D/D at the middle of the chain is breaking the clock chain and feeding the D/A converter with a cleaner clock. Is that correct?

Well, first of all, I'm pretty darn skeptical about the concept of upsampling in front of what is already an oversampling DAC in the first place! DCS should and could build all of that into the DAC with a single filtering system instead of rooking you for thousands of thousands of unnecessary dollars. I've heard a possible "improvement" using the 972, but as far as I'm concerned, it is totally unnecessary if DCS did their homework and did it right.

Secondly, you are NEVER really "breaking" a clock chain unless the sample rate converter is an asynchronous model. But since the DCS 972 is a synchronous sample rate converter its output rate is slaved by a ratio to the input rate and to the input PLL of the 972. The answer to your question of stability of the clock on the output of the 972 depends strictly on the quality of the Phase locked loop on the input of the DCS 972. It can be good, it can be bad, it can improve the jitter issue or make it worse. But the 972 has a good reputation for a good PLL, so it is probably attenuating the jitter on its input to a good extent. That's what you really meant by saying "breaking the clock chain", all it really means is the DCS 972 is attenuating its input jitter. And once again, DCS is charging you for something they should do better within the DAC! The DAC itself should contain a super quality PLL and there is no technical reason, other than DCS's pocketbook, why an additional "jitter reduction unit" should ever be needed in front of the DAC. If it does perform better, it is because the DAC itself is not built well enough.

But there is an even better choice you are better off making if it is possible to do this patch. DCS is extremely flexible in its clocking options. I believe that the DCS DAC allows you an option where it is the master and that can drive the wordclock of the 972, which can possibly work backwards and drive the M-Audio on external sync. Investigate that option, it will make the DAC stable as a rock.

Then the A/D on the other side of the analog processing can be on internal sync if it is feeding an additional (independent) DAW, which would be your best case, a win-win situation, you are running internal clock for both converters. It would be your case anyway if you are running a different rate in the A/D.

But if you are feeding your A/D back into the same DAW, then your best choice is to put the a/D on internal sync, lock the M Audio to that, and then you are forced to lock the DAC to the M Audio with whatever help the 972 provides.

Hope this helps!

BK

[Homero]

bobkatz wrote on Sun, 13 March 2005 23:06

Homero wrote on Sun, 13 March 2005 14:57 I have a variation of the theme here. I have started to use a cheap M-Audio Firewire interface to speedy up some tasks related to SRC. That interface uses an ASIO driver and Digital Performer supports it. My chain is: M-Audio (internal sync) SPDIF out--->dCS 972 D/D (SRC UP-Sample)---->dCS 954 D/A----> analog processing... I believe that the dCS 972 D/D at the middle of the chain is breaking the clock chain and feeding the D/A converter with a cleaner clock. Is that correct? Well, first of all, I'm pretty darn skeptical about the concept of upsampling in front of what is already an oversampling DAC in the first place! DCS should and could build all of that into the DAC with a single filtering system instead of rooking you for thousands of thousands of unnecessary dollars. I've heard a possible "improvement" using the 972, but as far as I'm concerned, it is totally unnecessary if DCS did their homework and did it right. Secondly, you are NEVER really "breaking" a clock chain unless the sample rate converter is an asynchronous model. But since the DCS 972 is a synchronous sample rate converter its output rate is slaved by a ratio to the input rate and to the input PLL of the 972. The answer to your question of stability of the clock on the output of the 972 depends strictly on the quality of the Phase locked loop on the input of the DCS 972. It can be good, it can be bad, it can improve the jitter issue or make it worse. But the 972 has a good reputation for a good PLL, so it is probably attenuating the jitter on its input to a good extent. That's what you really meant by saying "breaking the clock chain", all it really means is the DCS 972 is attenuating its input jitter. And once again, DCS is charging you for something they should do better within the DAC! The DAC itself should contain a super quality PLL and there is no technical reason, other than DCS's pocketbook, why an additional "jitter reduction unit" should ever be needed in front of the DAC. If it does perform better, it is because the DAC itself is not built well enough. But there is an even better choice you are better off making if it is possible to do this patch. DCS is extremely flexible in its clocking options. I believe that the DCS DAC allows you an option where it is the master and that can drive the wordclock of the 972, which can possibly work backwards and drive the M-Audio on external sync. Investigate that option, it will make the DAC stable as a rock. Then the A/D on the other side of the analog processing can be on internal sync if it is feeding an additional (independent) DAW, which would be your best case, a win-win situation, you are running internal clock for both converters. It would be your case anyway if you are running a different rate in the A/D. But if you are feeding your A/D back into the same DAW, then your best choice is to put the a/D on internal sync, lock the M Audio to that, and then you are forced to lock the DAC to the M Audio with whatever help the 972 provides. Hope this helps! BK

Thank you very much Bob, I need some more time to investigate this patch and as soon as possible I will be reporting the results.
I didn't brought the dCS 972 only to do this work so I think its worth the investment.

I would like to clarify one point more:

The digital output of the M-Audio Interface is SPDIF only, so I can't interface directly with the 954 D/A that has only AES Ins.

[Roland Storch]

TotalSonic wrote on Sun, 13 March 2005 00:26

Depending on the soundcard and ASIO drive implementation one thing that ASIO might be doing math wise that does not happen with MME is that it converts fixed point numbers to floating point. fwiw - Bob Lentini, SAWStudio's author and a person I consider the best DAW app programmer around, has been pretty critical of the ASIO protocol, even though he added support for it a few years back. Here's some quotes in response to the reasons he doesn't like it: ASIO... I don't like the loosness of it... drivers try to control the app... it should be the other way around, in my opinion.... the driver simply needs to move data to and from ram as efficiently as possible... not take control of everything and dictate buffer formats and sizes etc to the app. ASIO is too easily stepped on by Windows and other threads... there is no room whatsoever for any interruptions in data flow... which will ALWAYS happen at the most inopportune times in Windows... when it does... ASIO spits out repeats of the last buffer... horrible sound... With ASIO... there is only one buffer playing... and one filling... any interruptions whatsoever... and you have a glitch... and a nasty one at that in most cases... Best regards, Steve Berson

If ASIO has all these problems,  how do DAWs like Soundscape, Sadie or Mac based Sonic handle that. Do they also have these problems with interruptions in data flow or the right buffer size?

[TotalSonic]

Roland Storch wrote on Mon, 14 March 2005 19:44

If ASIO has all these problems,  how do DAWs like Soundscape, Sadie or Mac based Sonic handle that. Do they also have these problems with interruptions in data flow or the right buffer size?

From my understanding it's a problem with the way priority threading is handled in Windows - so all apps using ASIO2 with Windows are subject to this problem.  I don't know the internals of OSX so I can't answer in regards to current Mac apps.

You'll only truly hear the glitching Bob L. is describing in an obvious way if you try and run latencies extremely low - i.e. 1 buffer of 64 samples - and then start loading the cpu up and start doing things like scrolling up and down tracks (i.e. forcing Windows to do quick screen redraws).  With his DWave protocol (I have a Mixtreme card for my home project studio's DAW so I've tested this stuff) you can load the session, run at a low latency, and then scroll around like mad and things won't break up like they will using ASIO2 if you get to the "edge"of cpu and track load.  Mind you that with SAWStudio that means a heckuva lot of tracks running a heckuva lot of processes to get to this point - something that I am sure no one in a mastering environment ever gets close to.  Still makes you wonder - can there be a point where glitches from thread interruptions not be obvious but still exist???

Best regards,
Steve Berson

[Ronny]

TotalSonic wrote on Mon, 14 March 2005 21:36

Roland Storch wrote on Mon, 14 March 2005 19:44 If ASIO has all these problems,  how do DAWs like Soundscape, Sadie or Mac based Sonic handle that. Do they also have these problems with interruptions in data flow or the right buffer size? From my understanding it's a problem with the way priority threading is handled in Windows - so all apps using ASIO2 with Windows are subject to this problem.  I don't know the internals of OSX so I can't answer in regards to current Mac apps. You'll only truly hear the glitching Bob L. is describing in an obvious way if you try and run latencies extremely low - i.e. 1 buffer of 64 samples - and then start loading the cpu up and start doing things like scrolling up and down tracks (i.e. forcing Windows to do quick screen redraws).  With his DWave protocol (I have a Mixtreme card for my home project studio's DAW so I've tested this stuff) you can load the session, run at a low latency, and then scroll around like mad and things won't break up like they will using ASIO2 if you get to the "edge"of cpu and track load.  Mind you that with SAWStudio that means a heckuva lot of tracks running a heckuva lot of processes to get to this point - something that I am sure no one in a mastering environment ever gets close to.  Still makes you wonder - can there be a point where glitches from thread interruptions not be obvious but still exist??? Best regards, Steve Berson

The difference between ASIO and MME or any other audio driver is that some systems operate more stable with one or the other. As far as changing the sound of the audio when going through an AES/EBU port,with the same clock, I don't thinks so, you may get dropouts, clicks, pops stuff like that but degrading the audio itself, I'd blame it on something else. You guys should stop listening by yourself and get someone to administer the tests to you in the blind. You are better off realizing that human ears are not perfect and they are prone to making mistakes, especially when you evaluating audio examples where differences are very minute or where there is no logical reason to be hearing differences.

[Homero]

bobkatz wrote on Sun, 13 March 2005 23:06

Homero wrote on Sun, 13 March 2005 14:57 I have a variation of the theme here. I have started to use a cheap M-Audio Firewire interface to speedy up some tasks related to SRC. That interface uses an ASIO driver and Digital Performer supports it. My chain is: M-Audio (internal sync) SPDIF out--->dCS 972 D/D (SRC UP-Sample)---->dCS 954 D/A----> analog processing... I believe that the dCS 972 D/D at the middle of the chain is breaking the clock chain and feeding the D/A converter with a cleaner clock. Is that correct? But there is an even better choice you are better off making if it is possible to do this patch. DCS is extremely flexible in its clocking options. I believe that the DCS DAC allows you an option where it is the master and that can drive the wordclock of the 972, which can possibly work backwards and drive the M-Audio on external sync. Investigate that option, it will make the DAC stable as a rock. Then the A/D on the other side of the analog processing can be on internal sync if it is feeding an additional (independent) DAW, which would be your best case, a win-win situation, you are running internal clock for both converters. It would be your case anyway if you are running a different rate in the A/D. But if you are feeding your A/D back into the same DAW, then your best choice is to put the a/D on internal sync, lock the M Audio to that, and then you are forced to lock the DAC to the M Audio with whatever help the 972 provides. Hope this helps! BK

I did a new patch following the directions you gave me.

Some patches could look strange but remember that M-Audio Firewire Interface doesn,t have any WC In, only SPDIFs In and Out.

dCS 904 (used as a master clock only) WC to---> 954D/A WC to---> 972 (Format Convert Only, no SRC)  SPDIF Out---->M-Audio In (External Clock)--->M-Audio Out--->972 SPDIF In--->972 AES Out --->954D/A AES In----> Analog Chain

I bit complicated but sounds amazing.

Following the analog chain the basic patch is:

Analog chain--->dCS 904 (Internal Clock)--->Weiss (Eq/Comp)--->dCS 974--->Sonic HD Recording (External Clock)

(Digital Performer can do the MIDI automation for Weiss too).

Best Regards

[bobkatz]

Homero wrote on Tue, 15 March 2005 19:15

dCS 904 (used as a master clock only) WC to---> 954D/A WC to---> 972 (Format Convert Only, no SRC)  SPDIF Out---->M-Audio In (External Clock)--->M-Audio Out--->972 SPDIF In--->972 AES Out --->954D/A AES In----> Analog Chain I bit complicated but sounds amazing.

Sounds like this might do much better! So I was wrong, the DAC doesn't have a master choice? I could swear from the DCS manual there was a special "master" mode you could put the DAC in where it produced a wordclock out or an AES out.

But I dunno, I don't have the boxes here.

BK

[zetterstroem]

ronny wrote:

"You guys should stop listening by yourself and get someone to administer the tests to you in the blind. You are better off realizing that human ears are not perfect and they are prone to making mistakes, especially when you evaluating audio examples where differences are very minute or where there is no logical reason to be hearing differences."

the thing ammitsb

[bblackwood]

ZETTERSTROEM wrote on Tue, 15 March 2005 23:52

the thing ammitsb Brad Blackwood euphonic masters Homero Newbie Offline Posts: 16 Re: DAW systems explained! bobkatz wrote on Tue, 15 March 2005 22:34 Homero wrote on Tue, 15 March 2005 19:15 dCS 904 (used as a master clock only) WC to---> 954D/A WC to---> 972 (Format Convert Only, no SRC)  SPDIF Out---->M-Audio In (External Clock)--->M-Audio Out--->972 SPDIF In--->972 AES Out --->954D/A AES In----> Analog Chain I bit complicated but sounds amazing. Sounds like this might do much better! So I was wrong, the DAC doesn't have a master choice? I could swear from the DCS manual there was a special "master" mode you could put the DAC in where it produced a wordclock out or an AES out. But I dunno, I don't have the boxes here. BK Indeed the dCS 954 doesn't have a "Master Clock Mode" , it needs a clock source to generate a WC Out Nevertheless that (complicated !) setup served the purpose of testing how could I drive two systems (DPerformer and Sonic) from the same computer. Now, I will look for a better Firewire Interface with WC options. Thank You very much Homero Lotito Reference Mastering homero@referencestudio.com.br www.referencestudio.com.br Print Pages: 1 [2] 3  All   Go Up « previous next » R/E/P Community > R/E/P > R/E/P Archives > Brad Blackwood > DAW systems explained!   SMF 2.0.19 | SMF © 2021, Simple Machines | Terms and Policies XHTML RSS WAP2 Site Hosted By Ashdown Technologies, Inc. Page created in 0.094 seconds with 19 queries.

[Homero]

bobkatz wrote on Tue, 15 March 2005 22:34

Homero wrote on Tue, 15 March 2005 19:15 dCS 904 (used as a master clock only) WC to---> 954D/A WC to---> 972 (Format Convert Only, no SRC)  SPDIF Out---->M-Audio In (External Clock)--->M-Audio Out--->972 SPDIF In--->972 AES Out --->954D/A AES In----> Analog Chain I bit complicated but sounds amazing. Sounds like this might do much better! So I was wrong, the DAC doesn't have a master choice? I could swear from the DCS manual there was a special "master" mode you could put the DAC in where it produced a wordclock out or an AES out. But I dunno, I don't have the boxes here. BK

Indeed the dCS 954 doesn't have a "Master Clock Mode" , it needs a clock source to generate a WC Out

Nevertheless that (complicated !) setup served the purpose of testing how could I drive two systems (DPerformer and Sonic) from the same computer. Now, I will look for a better Firewire Interface with WC options.

Thank You very much