Lynx, Cubase 4 WinXP, multiple UAD users: Can anyone confirm or refute this?

[DAWgEAR]

As I mentioned in the initial post, I posted about this in several forums, figuring that users of all three of Cubase, Lynx, and multiple UAD-1s on WinXP would be a fairly narrow intersection.

To date, aside from drmad69's findings, which I knew of beforehand, only 1 other user (thank you!) has reported results, and only for procedure 1 (the result confirmed my experience).

The discussions have evolved somewhat differently and there have been many good suggestions (thank you!) and several apparent dead ends.

For sake of completeness, and for the benefit of somebody in the future stumbling upon this thread with similar issues, I will am posting links to the other threads:

UAD Forums • View topic - Lynx, Cubase 4 WinXP, multiple UAD users: Can anyone confirm

Lynx Support Forum: Lynx, Cubase 4 , multiple UAD users

Cubase.net ::: View topic - Lynx, Cubase 4 WinXP, multiple UAD users: Can anyone confirm

[Schaap]

Hi DAWgear,

As reported I have 2 dropouts in procedure 1.
I had to connect my new Eventide 2016( ) so I could do the procedure 2 easily too now as you described.

With buffersetting 512 samples of the two Lynx AES cards I found a delayshift in track 3 of 512 samples so 1x buffersetting. That confirmes your findings.

Cubase 3.1, 2 UAD(PCI), 2 lynx AES(SRC), Windows XP

Henk

[Oldone]

Originally Posted by DAWgEAR

Oldone, I would greatly appreciate it if you could try the procedure(s) on Sonar and report back.

It would be a major step forward in the troubleshooting to verify that either

(i) no Cubase = no dropouts (or at least lower likelihood of dropouts)

or

(ii) dropouts occurs with both Cubase and Sonar.

Got home late from work but will try to knock this out tonight.

[Oldone]

I could only do test 1 as Sonar does not have editing for drawing samples. Sorry about that.

The first time I did the first test I put in the LA2A. No dropouts. Then I put in the 1176 right after it. Still no dropouts in Sonar 7.

I did find a bug in Sonar when I zoom all the way on the silent audio. If you go to maximum resolution using samples as the view mode, Sonar crashes, everytime.

Last I repeated this test only inserting the 1176 first. I got a drop out of 1. Then I inserted the LA2A and nothing further happened. This situation only occurred once. Subsequent tries did not create any dropouts with the 1176 first.

As I said above, this is with 2 UAD1s the first is PCI, the other is PCIe. Lynx IIA, ASIO 256 buffers. Vista 64, Sonar 64. Latest drivers on all.

[DAWgEAR]

Oldone, many thanks for trying and reporting back.

It looks like the problem is considerably less severe with Sonar. That is an interesting clue in this puzzle.

Evidently dropouts, to the extent that they ever happen, will be less frequent with Sonar. The question that remains is whether new recordings will lose sync with the pre-existing tracks if and when the dropout occurs.

If you can't draw samples, you might consider using some audio with a well defined transient attack, maybe a high hat sample. The delay, if present might not be exactly the buffer size in samples (64), but it should be close enough to observe if it is even happening.

Another quick and easy test would be to trying procedure 2 by just sticking an SM57 a quarter inch in front of your monitor speaker and recording a soloed source with good transient definition, again maybe a hi hat. The delay won't be exactly a multiple of the buffer size due to the fraction of a millisecond that the quarter inch of air travel will induce, but you will know by visually inspecting the source and the recorded waveforms if things aren't correctly synchronized.

That is, assuming you can trigger another dropout first.

If there is no delay, then we would know that Cubase is involved and Sonar isn't ...

Something to consider if you feel up to it. You've already helped a lot with what you've done.

Thanks again.

[steveschizoid]

Hey DAWgEAR, I finally got around to trying your test, and there is something definitely wrong with this system. I did get the dropout - with the first instance of the UAD-1 plug. I couldn't get he draw function to play back my spike (?) so I just recorded a noise onto a track, then ran it out a mono bus then back in. It recorded earlier on the new track. Have you seen this behaior before? Anyone? I have the new AES16e and 3 UAD-1 (2 pci, 1 pcie) and use cubase. After I reset the card it behaved more as you would expect - it was delayed by about 5 samples. So basically the workaround is to make sure you check for dropouts before you record anything important, right? I have had some other irritations with this system, but I am sure it has to do with UAD-1's and the AES16 fighting over resources, which isn't supposed to happen with PCIe. I had a 5 year nightmare with Aardvark, so this issue feels relatively tame, but I do agree that, for the money we all have invested, this sort of crap should not happen. Each company will blame the other and nothing will change. For me it's easiest to get in the habit of checking than to sell the card and cables and switch to RME, which may have issues as well. Someone should email Paul and David a link to this thread.

[DAWgEAR]

Andy (sorry I called you Steve before),

First of all, thanks for trying the test. I appreciate you taking the time to do so.

I do get occasional random dropouts, sometimes even upon creating a new empty project before loading any plugins. It is not surprising that you got a dropout on the first plugin, but I'm guessing you will not be able to replicate the experience 100% of the time (I could be wrong). For me, the same is true of drmad69's suggestion of repeatedly minimizing/maximizing the Cubase window: I sometimes can trigger a dropout that way, but not always. I mentioned the 2 UAD-1 plugins across multiple UAD-1 cards, because, on my system, that always produces a dropout without fail (I've tried it hundreds of times at this point!). Other systems may behave differently, this is partly what we are trying to figure out.

As far as the recorded audio being early, I have not experienced that. That is a new observation to me. The fact that you report a 5 sample offset even after reseting the ASIO driver is also unusual. Which leads me to thinking ...

I hope I am not offending you by asking this, but in Cubase 4 under Devices Menu>Device Setup>VST Audio System there is a field called Record Shift ... the idea is to manually compensate for any record delay offset. You determine this value with a test much like my procedure 2 (of course, without a dropout showing in the Lynx mixer!). Have you set this parameter up correctly?

With the Lynx v14 driver and earlier, the offset was 1 sample on both my old and new systems. With the v15 driver, that parameter needs to be 67 samples on my new system. You have the AES16e, so the value may be different on your system.

Here is link that explains the above setting:

Cubase.net ::: View topic - How to measure audio recording offsets

For me, the workaround is to set up my Lynx Mixer and Cubase windows as in the attached screenshot image below. You can see the very left edge of the Lynx Mixer peeking out from behind the Cubase window, and you can see the dropout alert as the red box. As soon as I see the red box, I reset the ASIO driver in Cubase (Devices Menu>Device Setup>VST Audio System>Reset).

Now that I know what to look for and what to do, it's inconvenient, but not a disaster. For the first year+ that I was experiencing delayed recordings and did not not know why, it was disastrous: unexplained sloppy timing, phase issues, inability to reliably use external effects in Cubase, etc. Parallel New York-style compression using outboard gear? Ouch.

My suspicion is that there are a lot of people out there unaware that they have this problem. There are no obvious symptoms: no audible glitches, no crashes, no errors, no BSODs, no driver conflicts ... the only symptom is slightly out of sync recordings.

Really, the only way to find out if you are or are not affected is to trigger a dropout by some method and then perform procedure 2.

Speaking for myself, I'm not sure whose "fault" this is. That is what I am trying to track down, and hopefully with enough feedback from other users, we will. I know that if I have only one UAD-1 card installed, this rears its ugly head a lot less frequently. One other user's findings suggest that this is less of a problem with Sonar than it is with Steinberg products.

To me there are two issues:

(1) Why are the dropouts happening in the first place? I get them with a buffer of 1024 samples. With transport stopped. In theory, I/we shouldn't even be experiencing dropouts in an empty project with a buffer that high during playback, much less in Stop mode! That could be a Lynx issue, a UAD-1 issue, a Steinberg issue, or some interaction between all three. It could even be some other overarching factor common to the systems that experience this behavior. Maybe the Lynx Mixer is just the messenger ...

(2) Given that a dropout does occur, why do the playback and record streams get out of sync? I believe that this is clearly a Lynx driver issue. We are getting dropouts when the audio engine is in Stop mode, not during playback. And once the dropout occurs, every subsequent recording is out of sync until the driver is reset.

I do hope that Paul and David can perform the procedures and comment on this issue.

[DAWgEAR]

Andy, another thought: go into the UAD-1 meter, System Configuration page and try disabling two of your three UAD-1 cards. Do you still get the dropout?

[steveschizoid]

No offense! I was totally unaware of the manual record delay compensation, let alone the need for it. Should this setting stay the same irregardless of the buffer setting and/or sample rate? Perhaps a stupid question - would this problem (and its solution) impact the way overdubbed recordings are timed? Would all overdubs be delayed 5 samples unless I used the manual delay compensation? I wonder if this is peculiar to my system, the AES16e or the AES16 as well.

The dropouts don't happen if I disable 2 of the 3 cards.

[drmad69]

Alot of times the audio is still offset after asio reset, because
at low buffer sizes, a initial dropout happens while it's resetting..


This is why I felt like I was chasing my own tail as regards to the recording timing.

It was impossible to predict..

I *AM* not surprised the -e does it. This is another example of how QC
at lynx is .

and I too felt as though for 3 years I was on.


They were only interested in selling aurora when it came out; because it's obviously

their cash cow now... but it seems they have the same QC with it and eventually

people will steer away from them. It's just that tooo many users think they are ok

when in fact, the driver carefully masks all the evil it does.

[drmad69]

This is what led me to reading the sdk.

They clearly didn't have a plan for dealing with dropouts and are

experimenting with the new drivers to see what works.

12 months ago they wouldn't bother, 6 months ago david started

hacking changes after I clearly pointed out the text in the sdk

that loosely explains how to deal with dropouts.


The problem is; there is no set way to do it. *LOGICALLY* if you think it out

and as a group we did it's not that hard.


#1. If you mask the dropouts per stream when a dropout happen you never hear
a click. This was their original logic. This keeps customers from noticing the issue.
RME's card clicks.
#2. After deciding to change it they did *PLAYBACK* only. not record too. So if you correct your playback stream and you are doing a lookback; the record stream quickly gets out of sync by buffersize&dropouts.
#3. If you dropout ALL the streams (which I suggested and as far I know hasn't been done.) like the RME, then; you will hear a pop-click in the audio;

***BUT*** you are BACK IN SYNC AFTER THE FRIGGIN DROPOUT. ***RATHER*** then having the rest of you data for the life of a session before ASIO reset being
*WRONG*. WITH THE CASE OF THE EXTERNAL FX, which is what I really wanted
fixed. (a loopback of sorts...)
ABSOLUTELY EVERYTHING GETS THIN and OUT OF PHASE AFTER the dropout.

I'D MUCH RATHER HAVE THE DARN CLICK; #1 I CAN HEAR WHEN IT'S HAPPENING
AND SEE IF THERE IS SOMETHING IN-2-DO with my system causing it WHEN it happens.
AND #2. The REST of my steam is in sync.

So, IF YOU DO A NYC SYLE COMPRESSION BUS/S with a EXTERNAL FX.
LIKE *ALOT* of people do. AND YOU GET A DROPOUT.. YOU TOTALLY RUIN
DELAY COMPENSATION as you are off as it you had NEVER compensated.



***IT IS OBVIOUS THEY HAVEN'T GOT A FIX WORKED OUT AND HAVEN'T ADDRESSED IT.***

FOR #$%#@% SAKE, THEY RELEASE AN ENTIRE NEW HARDWARE CARD WITHOUT
FIXING a SHOWSTOPPER. *THE* *ONLY* REASON THEY GET AWAY WITH IT,
IS BECAUSE PEOPLE DON'T HEAR IT HAPPENING.

YOU *WILL* GET DROPUTS WITH 1 UAD, ITS JUST NOT AS COMMON.

DO THE SCREEN MINIMIZE AND IT WILL DROPOUT.

THERE IS SOME REALLY BAD CODE IN THEIR DRIVER THAT CAN'T

TOLERATE *COMMON* buss delays. They are delays that *SOMEHOW*
other manufacturers are protected from.

I dont remember how but I have got the audio to appear early by buffersize/dropot # as well.

The screen minimize/maximize proves it, something in the windows code

does a buss reservation that HOSES the lynx driver, but not always on the

same conditions.

Originally Posted by DAWgEAR

Andy (sorry I called you Steve before),

First of all, thanks for trying the test. I appreciate you taking the time to do so.

I do get occasional random dropouts, sometimes even upon creating a new empty project before loading any plugins. It is not surprising that you got a dropout on the first plugin, but I'm guessing you will not be able to replicate the experience 100% of the time (I could be wrong). For me, the same is true of drmad69's suggestion of repeatedly minimizing/maximizing the Cubase window: I sometimes can trigger a dropout that way, but not always. I mentioned the 2 UAD-1 plugins across multiple UAD-1 cards, because, on my system, that always produces a dropout without fail (I've tried it hundreds of times at this point!). Other systems may behave differently, this is partly what we are trying to figure out.

As far as the recorded audio being early, I have not experienced that. That is a new observation to me. The fact that you report a 5 sample offset even after reseting the ASIO driver is also unusual. Which leads me to thinking ...

I hope I am not offending you by asking this, but in Cubase 4 under Devices Menu>Device Setup>VST Audio System there is a field called Record Shift ... the idea is to manually compensate for any record delay offset. You determine this value with a test much like my procedure 2 (of course, without a dropout showing in the Lynx mixer!). Have you set this parameter up correctly?

With the Lynx v14 driver and earlier, the offset was 1 sample on both my old and new systems. With the v15 driver, that parameter needs to be 67 samples on my new system. You have the AES16e, so the value may be different on your system.

Here is link that explains the above setting:

Cubase.net ::: View topic - How to measure audio recording offsets

For me, the workaround is to set up my Lynx Mixer and Cubase windows as in the attached screenshot image below. You can see the very left edge of the Lynx Mixer peeking out from behind the Cubase window, and you can see the dropout alert as the red box. As soon as I see the red box, I reset the ASIO driver in Cubase (Devices Menu>Device Setup>VST Audio System>Reset).

Now that I know what to look for and what to do, it's inconvenient, but not a disaster. For the first year+ that I was experiencing delayed recordings and did not not know why, it was disastrous: unexplained sloppy timing, phase issues, inability to reliably use external effects in Cubase, etc. Parallel New York-style compression using outboard gear? Ouch.

My suspicion is that there are a lot of people out there unaware that they have this problem. There are no obvious symptoms: no audible glitches, no crashes, no errors, no BSODs, no driver conflicts ... the only symptom is slightly out of sync recordings.

Really, the only way to find out if you are or are not affected is to trigger a dropout by some method and then perform procedure 2.

Speaking for myself, I'm not sure whose "fault" this is. That is what I am trying to track down, and hopefully with enough feedback from other users, we will. I know that if I have only one UAD-1 card installed, this rears its ugly head a lot less frequently. One other user's findings suggest that this is less of a problem with Sonar than it is with Steinberg products.

To me there are two issues:

(1) Why are the dropouts happening in the first place? I get them with a buffer of 1024 samples. With transport stopped. In theory, I/we shouldn't even be experiencing dropouts in an empty project with a buffer that high during playback, much less in Stop mode! That could be a Lynx issue, a UAD-1 issue, a Steinberg issue, or some interaction between all three. It could even be some other overarching factor common to the systems that experience this behavior. Maybe the Lynx Mixer is just the messenger ...

(2) Given that a dropout does occur, why do the playback and record streams get out of sync? I believe that this is clearly a Lynx driver issue. We are getting dropouts when the audio engine is in Stop mode, not during playback. And once the dropout occurs, every subsequent recording is out of sync until the driver is reset.

I do hope that Paul and David can perform the procedures and comment on this issue.

[drmad69]

OH, BTW, dawgear that reminds me...

There is a whole other issue. with the record offset/plugins..


*BECAUSE* this #$% is broken. It never calculates correctly and it drifts.


IT SHOULD BE like 60-80 samples. But when it says 1 sample; it has

been affected by a dropout that never got recorded in the display/driver/etc.


AND THAT IS WHY....

it's only a sample or two off.... because it subtracted/added buffersize + 1 dropout.

And therefor, cubase is thrown off when it looks at the ASIO timing info.


TRUST ME IT'S A CLUSTER.

The very *FIRST* thing I did when I got my new digicards was made sure that

#1. Those values were accurate according to the hardware sample delay numbers.

#2. The VALUE and PING times NEVER CHANGED +/- 1 sample.


According to lynx and the delay values on their interfaces, it ain't anything CLOSE

to under 10 samples total.


Now, I forget dawgear, do you have a multiproc system? not hyperthreading?

I have a couple of interesting suggestions for testing/discovering..

Like turnoff mp in cubase and such... But *NOTHING* fixes it.

[drmad69]

FWIW, for those that think they can just check the window for
dropouts and be good. I tried this for 3 months.

Besides being a total pita, as I just described, the timing still drifts

and it doesn't ALWAYS report a dropout.


THEREFOR the best thing to do is ASIO reset before every recording run...


THE PROBLEM WITH THAT IS.... ALOT of the TIME, you start off with 1 dropout

at anything below 256 buffer...


This makes it impossible to ever be in sync... TRUST ME... I TRIED...

I had those cards for 3 years. With 1 card it wasn't so bad, I didn't notice..

With the second card, I didn't track down all the details for nearly 2 years.

and even after finding the asio reset workaround... I finally gave up.

Because there is no way to be sure...



You guys need to send in dozens of different people on a list requesting

a tested fix. Or do something to make them drop all their other money making

projects and fix it.. Remember, they have you're money. They don't care;

They have to pay paul anyway. There is only 1 programmer, who is the

company owner... You think he's gonna fix aurora that makes money and

has about as many problems, or is he going to fix the new/old interface problem

that only about 5% of people are aware of?

Think about it.... And to me.. I still wonder if it's not a forklift upgrade... But,

releasing the -e with the samebug has made me wonder. If it's a problem

with their audio chipset, then they *can't* fix it and everybody's sol.

[stratton]

Originally Posted by DAWgEAR

stratton: I would appreciate any feedback. If loading plugins across the UAD-1 cards does not produce a dropout, try what drmad69 suggested regarding repeatedly minimizing/maximizing the DAW application window. Also, for the test to be comparable, you should use the ASIO driver, perhaps that is what you already use. Again, any feedback, affirmative or negative is appreciated. Assuming that you can trigger a dropout (you should be able to do this by setting the buffer low and stressing your system enough) make sure you try procedure 2.

Adding UA plugs to a track didn't produce a dropout, but minimizing SONAR during playback produced an audible crackle and dropout size 3. Dither was ON in the Lynx mixer.

Turning dither off in the mixer, repeating playback and minimizing SONAR during playback brought the droput size to 1, crackle still audible. Later I'll try this without UA plugs.

ASIO driver, 1023(?) buffer.

[drmad69]

OH WOW, with a 102x Buffer.. THAT SUCKS.
Was you machine loaded 100% or something?


Also; the driver hoses in a different way BTW, to all of you....

If you ever try to scrub, the cpu utilization will climb and eventually reach/peak

to 100% and back. on the asio meter..


The lynx driver pukes all over it's self if you every hit 100% too..

and I don't remember; but I think that required a hardboot to fix.


There is just *SO* much wrong with it; finding all of them takes a lifetime.

[drmad69]

did anyone re-open a call in lynx's call ticket system?

I had several, but there are all closed.

[DAWgEAR]

Maybe a visual image will convey the gravity of what is happening:

The image below shows the result of procedure 2. The ASIO buffer is set to 1024 samples. Why so high? Presumably to minimize the strain on my system and minimize the occurrence of a dropout. I'm monitoring through hardware, so software monitoring latency isn't an issue. It is also automatically compensated for by Cubase.

However, after adding 2 UAD-1 plugins, the Lynx Mixer shows 1 dropout in the Play 1 device (red box). Had I not looked at the Lynx Mixer, I would be unaware of this. Since the transport is stopped, Cubase gave me no warning that a dropout occurred (this is a Cubase Preferences setting, incidentally). And since transport was stopped when I loaded the plugins, I heard no audible glitch, crackle, or pop.

My reference "spike" is at 100,000 samples, where I have set a marker.

The Sample Editor shows the recording made by looping back output 1 into input 1. You can see that the recording of the "spike" is positioned at 102,048 samples. The distance between the marker and the recording is selected with the Range Tool, and you can see the selected range is 2048 samples. This time it is a multiple (twice) the buffer. Sometimes it's just one times the buffer, sometimes twice ... it appears to be random, but always an integer multiple.

At 44.1kHz sampling rate, 2048 samples is 43.42 milliseconds.

Unless I reset the ASIO driver, every recording I make hereafter for the duration of the session will be 43.42 milliseconds late compared to the pre-existing tracks.

Imagine if my client were a band and I recorded the drums yesterday and overdubs today. I'd be thinking, "Boy, their sense of timing sucks!" So would they.

If the buffer were smaller and the integer multiple happened to be one, it wouldn't be so audibly obvious. But it would still sound "wrong". Of course, as the buffer is lowered and the strain on the system increases, the likelihood of further dropouts increases ...

[DAWgEAR]

Originally Posted by steveschizoid

No offense! I was totally unaware of the manual record delay compensation, let alone the need for it.

I'm glad I mentioned it, then!

Originally Posted by steveschizoid

Should this setting stay the same irregardless of the buffer setting and/or sample rate?

I believe so, at least with buffer. I haven't checked sample rate changes, that might be something to test if you do decide to work at a different sample rate. Having just said that i don't know about sample rate, my tests indicate that it's set and forget, unless, of course, you update drivers or something. This whole business has gotten me so paranoid that I check periodically just to make sure.

Originally Posted by steveschizoid

... would this problem (and its solution) impact the way overdubbed recordings are timed? Would all overdubs be delayed 5 samples unless I used the manual delay compensation?

YES! It's a pretty important setting.

Originally Posted by steveschizoid

I wonder if this is peculiar to my system, the AES16e or the AES16 as well.

I would think that different systems might call for different offsets. Mine is 67, your could very well be 5 (or -5 since you are early). Experiment with the setting until your looped back recordings are sample synced.

Be aware that analog and digital loopbacks will have different offsets. I believe this is due to the slight delay introduced by the DA and AD stages, which don't apply to pure digital out/in paths. This can affect you if you have both analog and digital effects that you are using as external effects in Cubase or Nuendo.

[drmad69]

Yup, that's a great picture, explaing where it eats you a new rear.

It also throws external FX permanently off by the amount too.

Even if you change cubase's buffering mode; so that it does 1.5x buffer

in an attempt to fix the problem; albeit alot of dropouts never happen,

they will still happen and then; you are chasing your tail again.

(You can change cubase so that it warns you on dropout and does the 1.5x

buffer, this is safer and doesn't mess the driver up as much, but even it doesn't

work as a solid fix.)

And you're right.... With transport stopped; neither mode is going to warn you.

But; you might have a delay at that point. I think this is because it's constantly

streaming. So you can have asio "reset" on the no mouse selection AND do

the double buffering; But for some reasons, randomly; you'll get that single

dropout. And then it's all over; Becuase lynx isn't smart enough to fix it.

[DAWgEAR]

Originally Posted by drmad69

#1. If you mask the dropouts per stream when a dropout happen you never hear
a click. This was their original logic. This keeps customers from noticing the issue.
RME's card clicks.
#2. After deciding to change it they did *PLAYBACK* only. not record too. So if you correct your playback stream and you are doing a lookback; the record stream quickly gets out of sync by buffersize&dropouts.
#3. If you dropout ALL the streams (which I suggested and as far I know hasn't been done.) like the RME, then; you will hear a pop-click in the audio;

***BUT*** you are BACK IN SYNC AFTER THE FRIGGIN DROPOUT. ***RATHER*** then having the rest of you data for the life of a session before ASIO reset being
*WRONG*. WITH THE CASE OF THE EXTERNAL FX, which is what I really wanted
fixed. (a loopback of sorts...)
ABSOLUTELY EVERYTHING GETS THIN and OUT OF PHASE AFTER the dropout.

I'D MUCH RATHER HAVE THE DARN CLICK; #1 I CAN HEAR WHEN IT'S HAPPENING
AND SEE IF THERE IS SOMETHING IN-2-DO with my system causing it WHEN it happens.
AND #2. The REST of my steam is in sync.

So, IF YOU DO A NYC SYLE COMPRESSION BUS/S with a EXTERNAL FX.
LIKE *ALOT* of people do. AND YOU GET A DROPOUT.. YOU TOTALLY RUIN
DELAY COMPENSATION as you are off as it you had NEVER compensated.

That makes a lot of sense.

It would be better to know when the dropout is occurring and have the sync return rather than the way things work presently.

I would gladly make the trade off of having some occasional audible glitches in my recordings (as long as they are not constant) to not have the entire recording session be ruined and not even know that it had happened.

[drmad69]

Originally Posted by DAWgEAR

That makes a lot of sense.

It would be better to know when the dropout is occurring and have the sync return rather than the way things work presently.

I would gladly make the trade off of having some occasional audible glitches in my recordings (as long as they are not constant) to not have the entire recording session be ruined and not even know that it had happened.

Yes, exactly, but then everyone would have hear it and complained and they'd

have telegraphed to all the users their cards suck. Which is why they didn't do it.

[DAWgEAR]

Originally Posted by stratton

Adding UA plugs to a track didn't produce a dropout, but minimizing SONAR during playback produced an audible crackle and dropout size 3. Dither was ON in the Lynx mixer.

Turning dither off in the mixer, repeating playback and minimizing SONAR during playback brought the droput size to 1, crackle still audible. Later I'll try this without UA plugs.

ASIO driver, 1023(?) buffer.

Stratton,

Thanks for the report.

Did you try procedure 2?

It seems that, while Sonar can produce dropouts, they are less likely than in Cubase. As drmad69 has suggested, it appears that the driver must be agitated in a somewhat different way in Sonar than in Cubase.

The question that we still haven't answered is whether recordings are out of sync in Sonar once a dropout has occurred (and before the ASIO driver is reset).

Earlier in this thread, Oldone mentioned that performing procedure 2 is difficult in Sonar. My suggestions was

If you can't draw samples, you might consider using some audio with a well defined transient attack, maybe a high hat sample. The delay, if present might not be exactly the buffer size in samples (64), but it should be close enough to observe if it is even happening.

Another quick and easy test would be to trying procedure 2 by just sticking an SM57 a quarter inch in front of your monitor speaker and recording a soloed source with good transient definition, again maybe a hi hat. The delay won't be exactly a multiple of the buffer size due to the fraction of a millisecond that the quarter inch of air travel will induce, but you will know by visually inspecting the source and the recorded waveforms if things aren't correctly synchronized.

If you feel up to trying procedure 2, your feedback would be appreciated.

[drmad69]

Although nobodies confirmed it, I'm sure they are out of time in Sonar too.

The logic is that the recording stream doesn't account, period. Unless sonar

has extrasensory powers and can read the Lynx's playback dropout counter,

It's there too.


If it had external FX that's a choice too..This is where it become absolutely

unusable, because it creates phasey noises with any duplicate source and

makes things like drum busses become practically inaudible or sound like they

have a delay FX on them.


If anybody could even get it to work in samplitude that would be another test.

But as it's been widely discussed in the samplitude forum, those issues are

way worse and go and come back with versions.


I can't remember which other DAWS have recently adopted external FX, but

, I can't try it with Protools...

[drmad69]

And I don't know, he had dropouts in sonar at 1024 too.

According to Lynx's that aught to be damn near impossible to achieve...

A dropout at a 1024 buffer that is.

They claimed it wouldn't do it in a 1 gig machine..


But, it's a claim.... They've never released any public information. Just broken

beta and official release drivers.

[SoundsUnreal]

I have two AES16s that I have had about 2 yrs. With NO trouble.

Nuendo 3...now Nuendo 4

one UAD1 card...

XP pro...dualcore opterons. TYAN motherboard... usually running at 96k

really....no problems

don't understand??