Print

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

[Alan Meyerson]

My head is spinning.
Thanks to you all (I think).

So, just to bring it back to the basics,
- I'm recording my orch at 96.
- I am then mixing that at 96 and real time SRC'ing my pre-records from 44.1 to 96 using a Euphonix 727 on a Euphonix System5.
- I am then, unfortunately, DOWNSAMPLING my mixed stems to 48 (my delivery requirement) in real time using a 727.
- At the same time, I'm doing a 96 version of it into a seperate system.

Everyone okay with this?

It's an honor to be part of a discussion with all of you,
Alan

[Daniel Weiss]

danlavry wrote on Thu, 15 September 2005 22:15

In the first case (44.1 to 88.2KHz), the 2 data streams are synchronous. We agree here. Typicaly, there is one physical clock at a high integer multiple of both 44.1 and 48KHz. For example, a typical crystal oscillator at 11.2896MHz is divided by 128 to yield 88.2KHz and by 256 to yield 44.1KHz. Those clock trains run together synchronously, and if the original 11.2896MHz clock drifts up by 10 ppm (oarts per million), both 88.2 and 44.1KH drift up by 10ppm. The result is synchronous operation. The timing (frequency) relationship between the 2 clock trains is set “iron clad” to 2:1. But when we work in a real world audio studio, with one clock is set to 44.1KHz, and the other to 96KHz, we are talking about 2 physically different crystal clocks. Now say the 44.1KHz drifts up by say 7 ppm and the 96KHz drifts down by say 4ppm. The total relative drift is 11ppm. The frequency ratio changes with temperature, with component aging…

Ok, but Bob (I figure) and I haven't talked about such a scenario, we talked about one where the two rates (e.g. 44.1 and 96) are generated from the same "superclock" source and hence are synchronous. As in your example with 44.1kHz and 88.2kHz where the least common multiple is 88.2kHz, the least common multiple for 44.1kHz and 96kHz is 14.112MHz.

You wrote:

Quote:

As a rule, you are better off to stay within a ratio of 2:1 (such as 44.1 to 88.2) than to go for a non integer ratio such as 2.176870748.... (such as 44.1 to 96KHz). The integer ratio requires much simpler sample rate conversion - an asynchronous conversion. The non integer ratio takes much more computations therefore it has greater potential for errors.

You assume here that the 44.1 and 96 rates are asynchronous. That can be in a general case, but isn't necessarily so.

Daniel
www.weiss.ch

[danlavry]

Daniel Weiss wrote on Fri, 16 September 2005 04:59

danlavry wrote on Thu, 15 September 2005 22:15 But when we work in a real world audio studio, with one clock is set to 44.1KHz, and the other to 96KHz, we are talking about 2 physically different crystal clocks. Now say the 44.1KHz drifts up by say 7 ppm and the 96KHz drifts down by say 4ppm. The total relative drift is 11ppm. The frequency ratio changes with temperature, with component aging… Ok, but Bob (I figure) and I haven't talked about such a scenario, we talked about one where the two rates (e.g. 44.1 and 96) are generated from the same "superclock" source and hence are synchronous. As in your example with 44.1kHz and 88.2kHz where the least common multiple is 88.2kHz, the least common multiple for 44.1kHz and 96kHz is 14.112MHz. You wrote: Quote: As a rule, you are better off to stay within a ratio of 2:1 (such as 44.1 to 88.2) than to go for a non integer ratio such as 2.176870748.... (such as 44.1 to 96KHz). The integer ratio requires much simpler sample rate conversion - an asynchronous conversion. The non integer ratio takes much more computations therefore it has greater potential for errors. You assume here that the 44.1 and 96 rates are asynchronous. That can be in a general case, but isn't necessarily so. Daniel www.weiss.ch

One could, for example have a high frequency source, a 14.112MHz clock can be divided by 320 to yield 44.1KHz and the same 14.112MHz clock can be divided by 147 to yield 96KHz. That would indeed produce synchronous clock trains, and if one forces their SRC to receive those clocks, it is possible to have synchronous operation.

But A TYPICAL APPLICATION of SRC is NOT based on such a case.
You and Bob assumed one case, and I assumed the other but
THE VAST MAJORITY of studios I know have an independent clock such as a house sync, for the output clock, while the data comes in to the SRC is based on another physical clock rate. Such applications are NOT synchronous, and they call for an asynchronous SRC conversion.

I would certainly accept an argument that states clearly that one can force the 44.1 to 96 to be synchronus, by having a common high frequency clock and dividers. But as you agreed "the general case" of such conversion calls for an asynchronus.

It is correct to say that one can use synchronous techniques to accomplish asynchronous results, by imposing a quantizing time grid on the conversion. This is similar voltage in digital audio, quantized to say 16 bits (65384 grid lines) and so on...
When quantizing the voltage, we want the grid to be as fine as the noise floor. When quantizing the time, we want the grid to be as fine as jitter (time domain noise).

So how many "grid lines" of say 10psec fit between say 44.1KHz samples? With time between samples at about 22.7usec, you need a grid of about 2.27 million! Is it a big deal? Yes it is. So lets go for a time grid of 100psec (pretty crude from sampling time standpoint) and we still need 227000 grid lines. Why is it a big deal? Because in an ideal case, each grid line represents a complete and unique set of FIR set of coefficients. The “quantized” SRC, where we use a synchronous SRC to approximate an asynchronous SRC by “bouncing” between fine time grid lines, just takes too much coefficient storage.

Well, there are solutions, and the common one is to have a rather coarse grid (coefficient table), as large a table as we can reasonably fit into the silicon, and the fine grid will be computed by interpolation. Now this is an approximation! Some implementations work better then others, and in fact the various solutions have serious tradeoffs.

In other words, SRC is more than a magic box with data in/data out. The question was “what works best” and for what case.

1. In a studio environment, most 44.1 to 96 (or 96 to 44.1) are asynchronous, the clocks are independent and knowing where one clock transition is does not tell you where the other clock transitions are.

2. If one can stay within the bounds of 2:1, one can get better results (greatly simplified calculations).

3. Alternativly, one can get the better results if they operate the SRC from a single clock source with dividers. That calls for aditional hardware generating (and distributing) all the clocks in a studio from one high frequency source divisable to all the desired rates.

3. When operating with asynchronus clocks, my understanding of Bob and Daniel’s remarks is that “one can use a synchronous process” to do a job in an asynchronous case. That is how polyphase SRC works. But is it a synchronous SRC? Or is it an asynchronous SRC? The process is a synchronous one (bouncing between time positions on a synchronous grid). The application is asynchronous one, moving data from one clock to another clock that is not in sync.

I called it asynchronous conversion, because it reflects the user’s point of view.

Bob, do you still disagree with what I say?

Regards
Dan Lavry
www.lavryengineering.com

[bobkatz]

danlavry wrote on Thu, 15 September 2005 16:15

But when we work in a real world audio studio, with one clock is set to 44.1KHz, and the other to 96KHz, we are talking about 2 physically different crystal clocks.

Ahhh, yes, well in that case it would be asynchronous! That is intutively obvious. But let's take the 44.1 to 96K case with a synchronous SRC.  The SRC that I use  takes the 44.1 and multiplies it internally by a large rational number and then divides down to produce a 96K result that is synchronous with the input! This is done with a PLL, I believe.

You will get EXACTLY the correct number of samples out that you would expect and timed EXACTLY to the framing of the incoming signal.

I can swear to that because I run a timecode generator in jamsync that is locked to the output of the sample rate converter. Over one hour's time there is not one sample of drift.

Quote:

Perhaps you can explain what it is about my explanation that you disagree with. I am truly open to have my definition corrected. But so far, I believe that my understanding of asynchronous is generally correct ? when you can not have 2 clock trains relates in a predictable way, they are no longer synchronous.

I do not disagree with your definition as you applied it. I am simply saying that there is another way to do it, a SYNCHRONOUS way to derive an output clock at 44.1 kHz that is locked to a 96K input (and vice versa). The two are not integer related, but by multiplication and division you can arrive at some kind of "least common divisor" that is exactly synchronous with the source. Daniel would know the numbers used.

[bobkatz]

Alan Meyerson wrote on Thu, 15 September 2005 16:59

My head is spinning. Thanks to you all (I think). So, just to bring it back to the basics, - I'm recording my orch at 96. - I am then mixing that at 96 and real time SRC'ing my pre-records from 44.1 to 96 using a Euphonix 727 on a Euphonix System5. - I am then, unfortunately, DOWNSAMPLING my mixed stems to 48 (my delivery requirement) in real time using a 727. - At the same time, I'm doing a 96 version of it into a seperate system. Everyone okay with this? It's an honor to be part of a discussion with all of you, Alan

It's an honor to hear someone working with such good gear! I didn't quite follow why you are doing what you are doing, but I imagine that is the only way you can do it.

Ask Euphonix for the specs on their SRC. Is it a polyphase unit? What precision does it have? Do they have any FFT measurements? And finally: What does it sound like? To my ears, an inferior 96 to 44 conversion sounds grainy and less "cohesive".

BK

[bobkatz]

danlavry wrote on Fri, 16 September 2005 14:45

But A TYPICAL APPLICATION of SRC is NOT based on such a case.

Really? I can't tell you what is typical, but I can tell you what you can buy for your money. A mastering engineer buys an SRC box, he plugs it in, and captures its output. Both synchronous and asynchronous models are available. So, what's "typical" in the end?  The ones who can afford or wish to spend their budgets on the expensive models will never be typical. We all know that. So I guess the async models outnumber the sync models, that situation will never change due to the economics of the matter.

But most of the asynchronous models have external sync inputs so you can run them "synchronously" clock-wise, just not get as good sounding results, in the case of the cheap IC-based units.

Quote:

It is correct to say that one can use synchronous techniques to accomplish asynchronous results, by imposing a quantizing time grid on the conversion. This is similar voltage in digital audio, quantized to say 16 bits (65384 grid lines) and so on... When quantizing the voltage, we want the grid to be as fine as the noise floor. When quantizing the time, we want the grid to be as fine as jitter (time domain noise).

If I understand you correctly, I believe that is NOT the principle of the best synchronous SRCs. They use a PLL to multiply the input up to the least common multiple and then divide down. Since the DSP used to do the calculations does not depend on jitter, it works on a sample by sample basis with a polyphase filter, then the limits of the results are the noise floor and distortion of the DSP, NOT the jitter of the PLL.

Quote:

In other words, SRC is more than a magic box with data in/data out. The question was ?what works best? and for what case. 1. In a studio environment, most 44.1 to 96 (or 96 to 44.1) are asynchronous, the clocks are independent and knowing where one clock transition is does not tell you where the other clock transitions are.

I would only say "most" because of the economics of the affair, because if you buy a (more expensive, better sounding) synchronous SRC you will get a synchronous output clock from it. I take advantage of that clock and use it synchronously in my studio, though in most cases most people would just record the output of the SRC on an independent recorder or DAW so they wouldn't care if it was synchronous or not.

Quote:

2. If one can stay within the bounds of 2:1, one can get better results (greatly simplified calculations).

Well, no one can argue with a greatly simplified explanation. My greatly simplified response is that there are exceptions. Those exceptions include the Weiss, Prism, and DCS SRCs, which are synchronous, and deal with all the standard rates with no prejudice, either measured or audible, or if audible, shall we say, "barely", certainly not on the order of what you would get from an inferior synchronous conversion.

Quote:

3. When operating with asynchronus clocks, my understanding of Bob and Daniel?s remarks is that ?one can use a synchronous process? to do a job in an asynchronous case. That is how polyphase SRC works. But is it a synchronous SRC? Or is it an asynchronous SRC? The process is a synchronous one (bouncing between time positions on a synchronous grid). The application is asynchronous one, moving data from one clock to another clock that is not in sync.

In the case of the Weiss, DCS, and Prism units (there may be more but I am not aware), it is a fully-synchronous clock and a fully-synchronous SRC.

Quote:

I called it asynchronous conversion, because it reflects the user?s point of view.

I respect your point of view. Let's just say that if the output clock is framed to the input clock, then the two clocks are synchronous. I think it would be a bad idea to generalize and say that "everytime" you have a non-integer clock they  must be asynchronous.

Hell, we deal with non-integer locked and framed clocks in video all the time. That's what pullup and pulldown PLLs do in the video realm.

Quote:

Bob, do you still disagree with what I say?

Of course not! I analogize our discussion to one where people have to write 6 pages of semantic definition before they can realize that they agree on everything  

Bob

[danlavry]

bobkatz wrote on Sat, 17 September 2005 14:47

danlavry wrote on Thu, 15 September 2005 16:15 But when we work in a real world audio studio, with one clock is set to 44.1KHz, and the other to 96KHz, we are talking about 2 physically different crystal clocks. Ahhh, yes, well in that case it would be asynchronous!... You will get EXACTLY the correct number of samples out that you would expect and timed EXACTLY to the framing of the incoming signal. Quote: Perhaps you can explain what it is about my explanation that you disagree with.... I do not disagree with your definition as you applied it. I am simply saying that there is another way to do it, a SYNCHRONOUS way to derive an output clock at 44.1 kHz that is locked to a 96K input (and vice versa). The two are not integer related, but by multiplication and division you can arrive at some kind of "least common divisor" that is exactly synchronous with the source. Daniel would know the numbers used.

I can not take too much time because I am getting ready for the AES. But I do have to point out that your comment stating that:

"The two are not integer related, but by multiplication and division you can arrive at some kind of "least common divisor" that is exactly synchronous with the source. Daniel would know the numbers used "
is confusing, to say the least. Again, 44.1KHz and 96KHz ARE integer related, both can be divided directly from a single common clock such as 14.112MHz. As you pointed out in a later post, one can also do it with PLL's, such as multiply the 44.1KHz by 320 and divide it by 147. So they ARE INTEGER RELATED which is the reason you can force a synchronus conversion between 44.1 and 96KHz.

Once you realize the above fact, you also realize that you can not have a synchronous SRC at any ratio, such as 44.1KHz +/-10ppm or any drift or deviation, against a 96KHz with any drift or deviation. Even the smallest of mismatch builds up and you can compute the time it takes to skip a whole sample. That demand the use of an asynchronus conversion.

The first SRC I made in 1993 did not have the capability to between arbitrary frequencies. The input frequency range was wide, but the output was restricted to a choice of 3 crystal frequencies. I did not find many users! The product needed redesign to include a connector for receiving an external clock rate (such as house sync or audio workstation).

Say you have a source of 44.1KHz and you wish to convert it to 96KHz in a synchronous way. It does force the output to exactly track the input (tolerance, temperature drift, aging...).  Now, the only way I know to have the newly generated 96KHz "integer match" the source rate of 44.1KHz. Say you have a 96KHz house sync (or a DAW 96KHz clock). The source material (at 44.1KHz) must be driven by the 96KHz house sync. In other words, the machine clock destination should generate a clock for the source.

Say you have an independent stand alone 44.1KHz source, and you force a synchronous conversion to 96KHz. Say the house sync is at (96KHz + 10ppm), and the source is (44.1KHz -10ppm) (meaning the converted 96KHz is 96KHz -10ppm). Now you have a mismatch between a 96KHz house sync (or DAW clock) and the newly converted 96KHz audio.
You can not just send the audio in - it calls for a new SRC task, from (96KHz -10ppm) to (96KHz -10ppm). This time, your SRC is Asynchronous. At this point, you may have considered a one step Asynchronous 44.1KHz to 96KHz....

You said that you do not know what a typical application is. I believe that if you think about it, you really do know. We are both in the audio business, and it is our business to know. To my knowledge, the vast majority of users do not derive their 44.1KHz source from a clock made from the 96KHz destination.
The source can be a CDR, a tape, a disk, and they most often run on some internal clock. The user want to plug a clock for some output rate of the SRC, and that is an asynchronous process. A good example is the question that started this thread. The task is to up sample the synth, and if you wish precise matching of phase and clock edges between exsiting tracks to the SRC data, both SRC input clock and output clock should be driven by the DAW clock. Forcing the conversation to be synchronous requires an ADDITIONAL clock - a 44.1KHz derived from the house sync. Most people do not do it that way, not to mention that much of the gear (for playing of the original data) is not even capable of of syncing to an external clock.

I do not have solutions to all the answers. I think it is important that we state things accurately. Again, your post may create the wrong impression when you stated that:

"The two are not integer related, but by multiplication and division you can arrive at some kind of "least common divisor" that is exactly synchronous with the source. Daniel would know the numbers used".

The numbers 44100 and 96000 ARE integer related (and the numbers I stated - 14.200Mhz and 320 and 147 dividers will work). When they drift together by the exact same amount, they are still integer related, but in practice it requires a single common clock source.

When you can (and do) use such a single common source, you SRC is operating in a synchronous mode, and in fact it makes your polyphase work in a synchrounus mode.

But when you do not force such clocking, and most often you can not (lack of sync capability of the source, or need to match timing of other tracks) the conversion becomes asynchronous.
 
Regards
Dan Lavry
www.lavryengineering.com

[Alan Meyerson]

bobkatz wrote on Sat, 17 September 2005 14:50

Alan Meyerson wrote on Thu, 15 September 2005 16:59 My head is spinning. Thanks to you all (I think). So, just to bring it back to the basics, - I'm recording my orch at 96. - I am then mixing that at 96 and real time SRC'ing my pre-records from 44.1 to 96 using a Euphonix 727 on a Euphonix System5. - I am then, unfortunately, DOWNSAMPLING my mixed stems to 48 (my delivery requirement) in real time using a 727. - At the same time, I'm doing a 96 version of it into a seperate system. Everyone okay with this? It's an honor to be part of a discussion with all of you, Alan It's an honor to hear someone working with such good gear! I didn't quite follow why you are doing what you are doing, but I imagine that is the only way you can do it. Ask Euphonix for the specs on their SRC. Is it a polyphase unit? What precision does it have? Do they have any FFT measurements? And finally: What does it sound like? To my ears, an inferior 96 to 44 conversion sounds grainy and less "cohesive". BK

I'm doing it this way to be able to record my orchestra tracks at a high sample rate. Alot of times, I'm limited to recording orch at 44.1 or 48 depending on the project.
This is one of those times I have an option. My pre-records are at 44.1.

So, my choices are
- record orch at 44.1
- record orch at 96k (or 88.2) and real time downsample my orch at the mix to my pre-records sample rate
- record at 96k and real time UPSAMPLE my pre-records at the mix ..my choice.

[bobkatz]

Excuse me for not expressing the least common multiple language exactly enough. I  was too lazy to say it exactly (multiply up to the LCM, then divide down to the new rate).  But you knew what I meant, didn't you?

danlavry wrote on Sat, 17 September 2005 12:14

Say you have a source of 44.1KHz and you wish to convert it to 96KHz in a synchronous way. It does force the output to exactly track the input (tolerance, temperature drift, aging...).

If you mean that the PLL will go out of lock at a certain temperature, I think that is academic. The output will follow the input for a very wide range of sample rates. If you mean that the PLL in the SRC has a certain sample rate (frequency) acceptance window, it is made pretty wide since jitter of the PLL does not affect the DSP of the synchronous SRC. Fortunately this is not a D/A converter and the distortion of the DSP is completely independent of sample rate or jitter.

Quote:

Now, the only way I know to have the newly generated 96KHz "integer match" the source rate of 44.1KHz. Say you have a 96KHz house sync (or a DAW 96KHz clock). The source material (at 44.1KHz) must be driven by the 96KHz house sync. In other words, the machine clock destination should generate a clock for the source.

But if your DAW is the source, it feeds the synchonrous SRC a 44.1 K, out pops 96K synchronous to the 44.1 and that has to be stored on a different device regardless. No need for house sync or worry.  If the source is a CD player, a synchronous SRC works just fine as long as you are willing to lock the recorder to the source.  If you wish to upsample the CD player to 96K and use a synchronous converter, the DAW can slave to the end of that chain.

It's just a matter of orientation. So synchronous converters work fine if you feed them from the clock source that you wish to use.  If the source is a device that cannot be externally synched, the problem is only slightly more difficult than if you are using an asynchronous converter.

But if you have to keep everything on house sync then BY definition you have to use an asynchronous converter to record the output of a non-lockable CD player. Same as in video you have to use a frame synchronizer (or whatever they're called). No one genlocks to the world anymore.

As for varispeed, already cited, if you want to preserve the pitch shift then you cannot use a synchronous SRC.

So we keep some asychronous converters around when we encounter those situations.

In 99.9% of the cases around here the sources we have can be locked externally. We solve the house sync problem by using both an upsampling and downsampling synchronous converter. Say we want to upsample a LOCKABLE CD player to 96K. I feed house sync (96K) to a synchronous downsampler to 44.1, lock the CD player to that, and then capture the output of the CD player through the synchronous upsampler. Works fine.

In fact, I upsample and downsample synchronously in mastering almost every day. Source is a DAW at 44.1K, upsampled to 96K, through a bunch of processors, and then downsampled to 44.1 to capture in the DAW. Everything is synchronous.

BK

[bobkatz]

Alan Meyerson wrote on Sat, 17 September 2005 12:42

I'm doing it this way to be able to record my orchestra tracks at a high sample rate. Alot of times, I'm limited to recording orch at 44.1 or 48 depending on the project. This is one of those times I have an option. My pre-records are at 44.1. So, my choices are - record orch at 44.1 - record orch at 96k (or 88.2) and real time downsample my orch at the mix to my pre-records sample rate - record at 96k and real time UPSAMPLE my pre-records at the mix ..my choice.

I would think of the 96K as your "house sync" and upsample the prerecords to 96K in real time. If you had time, you could upsample them another day, when the clock is not ticking with conductor and orchestra. I'd feel more comfortable about it than doing it on a live session with orch, myself.

I suspect you need to downsample the 96K to 44 in order to lock the prerecords. If you have ANY doubts about the integrity of the SRC then definitely record to 88.2 K instead.

[danlavry]

Bob, You said:

"If you mean that the PLL will go out of lock at a certain temperature, I think that is academic. The output will follow the input for a very wide range of sample rates. If you mean that the PLL in the SRC has a certain sample rate (frequency) acceptance window, it is made pretty wide since jitter of the PLL does not affect the DSP of the synchronous SRC. Fortunately this is not a D/A converter and the distortion of the DSP is completely independent of sample rate or jitter."
[quote title=Quote:]

I say:

No I do not mean that at all. In order to operate synchronously, you need the frequencies to be related by integer related. It forces one to generate 2 sets of clocks that are integer related. If you have two external clocks (one at 44.1 and the other at 96KHz) that are derived from the SAME CLOCK SOURCE, that it is fine for synchronous SRC. Any drift will effect BOTH clocks so the ratio is maintained.

If you have 2 clock sources (one at 44.1 and the other at 96KHz) where each one is generated from its own SEPARATE CLOCK SOURCE, than it forces asynchronous conversion. You simply can not lock them together, and any drift in one clock, the other clock or both clocks will effect the ratio.

If you have both clocks derived EXTERNALY from one clock and,
If you can apply the 44.1KHz to lock the input to that rate and
If you can lock your SRC output to 96KHz, along with the DAW
Then you are in synchronous world.

But :
If you have both clocks derived INTERNALY inside the SRC, and you want to merge tracks with existing audio on a DAW, your output if not timed to match the DAW. You could try to correct it by having the SRC output act as a house sync. There are times when this is undesirable because it complicates other things. One way or the other, there are many scenarios, enough to confuse the vast majority of users. This is one of the issues that is not well understood by many users.

BTW, I did not know what you meant to say rerading the numbers being integer multiples. In fact, I thought you missed the point, and that is why I wrote the post.

But, I do agree with all the rest that you said.

Regards
Dan Lavry
www.lavryengineering.com  

[bobkatz]

danlavry wrote on Mon, 19 September 2005 13:26

BTW, I did not know what you meant to say rerading the numbers being integer multiples. In fact, I thought you missed the point, and that is why I wrote the post.

Language is so slippery! There were times when I though you lost the point  

BK

[Alan Meyerson]

Thanks everyone.  Session sucessfully completed!
All the best.
Alan

[Schallfeldnebel]

Mr. Lavry wrote: " As an engineer, I pay more attention to technical and less to language, so it is possible I am not using the language properly."

This was about the use of the word a-sync or sync sample rate converters. So, reading this thread I was a bit curious and went up your site, and there I found you designed a samplerate converter, and on your site it is said to be sychronous. I was just wondering, if you meant here also a-synchron.

Erik Sikkema

[danlavry]

ErikS wrote on Wed, 12 October 2005 19:41

Mr. Lavry wrote: " As an engineer, I pay more attention to technical and less to language, so it is possible I am not using the language properly." This was about the use of the word a-sync or sync sample rate converters. So, reading this thread I was a bit curious and went up your site, and there I found you designed a samplerate converter, and on your site it is said to be sychronous. I was just wondering, if you meant here also a-synchron. Erik Sikkema

Hi Erik

The Model 3000S has both settings:

1. Synchronous SRC
2. Asynchronous SRC

I recommend using the Synchronous when possible, for the reasons already stated.

I also have a plug in for the LavryBlue, and that one is a Synchronous SRC (a X2 or :-2). On one hand it is a very special purpose device, only for doubling and halving sample rate. On the other hand, it does the cleanest job, and without any of the phase issues of Asynchronous SRC's.

Note how some of the posts about SRC phase in this forum changed from claims of phase match to "almost phase matched", due to having the same rest... The point is - a Synchronous SRC is phase coherent...

Regards
Dan Lavry