<<But ready to learn and change if it makes my work better>>

Lesson. There is no need to partition drives on a DAW, it just shouldn't be done. It has potential for early wear on the drive anyway.
And don't even think about doing it to your audio drives.

JoeD

------"Are you trying to tell me that there is input latency? Do we have to manually adjust our tracks based on V4's inability to offset and place the track to its correct timeline position?"------

******yes...its a known issue. In some cases, vegas' " automatically adjust offset" or whatever its called works fine. In other cases you gotta do it yourself. Vegas 3 had finer adjustments for this than 4 does, but in ASIO there is no option ******

Pipe,

Here's a question:

If you software monitor the input of your RME, do you have latency at that point? If you don't, then there is not input latency....

What is apparently happening here is that there are different values of latency for the reproduction of a file. There should be no adjustments for this in any application. Timeline correction is not an afterthought it is fundamental requirement and it must be absolute.

There should be intentional latency (or offset of playback tracks) for playback which gives your DAW time to read/write to the hard drive and that should be mathmatically removed from the front of the newly recorded file when it is automatically rendered after record.

If there are timeline differences on the tracks you're cutting, then I would venture to say that these problems are occuring from this crazy way of monitoring (without auto input and trying to use input monitor which actually monitors the output of the application) and the choice of inserting realtime plugin effects.

I would not use a single plugin when tracking with the application. Each effect will provide a different amount of latency based on its method of processing.

Tell me, is anyone here experiencing these offset issues when there are no plugins selected when tracking?

If you guys are running plugins on the tracks your recording, or on your playback tracks, you will be incorporating differentials in your monitoring latency, which would explain why the tracks are not lining up.

It would further verify my opinion of the importance of "Auto Input" and the correct methods of multitrack monitoring.

If you monitor your armed track's instrument before the application everytime and don't use plugins, then the math required to offset the recorded track will never change.

Use outboard effects when tracking.

Now, if the program is still lining tracks up incorrectly without using plugins, quit using it.

Nobody can work with a multitrack like that.

Brett,

You are so right!

I think it may be a few different things that may be causing the occurence of these issues. I'm going to further investigate and run some tests as well and see if I can't get to the bottom of it.

Oh the importance of "Auto Input" and the correct methods of multitrack monitoring. There are very important reasons why we monitor multitrack recorders the way that we do....

Proper Multitrack Monitoring & how it applies to Vegas

I have a very strong feeling that the problem lies somewhere in the methods of routing the armed track for monitoring within the application combined with the results of using realtime effects and the potential offset issues that can be introduced when doing this.

Okey smokey,

Just did some testing, using two different soundcards and two different systems on both Vegas 3 and 4.

The soundcards are a Tascam US-428 and a Turtle Beach Santa Cruz.

My office system is an Athlon 1000 (overclocked to 1250) running on an Abit KT7 mainboard with 256 MB. 2 IDE HDDs, CD burner, USB ADSL modem, PCI Savage 4 video. Win XP pro, SP1+. It is a jack of all trades, has every software application ever written installed on it. (Despite its clutter it runs very smoothly)

The studio system is an Athlon 2400 XP running on a Gigabyte Ga-7vrxp with 512 MB. 1 IDE HDD, CD burner, PCI Savage 4 video. Win XP pro (no SP1). Used exclusively audio, only audio applications and plug-ins installed.

I imported a mono 16/44.1 file (a one bar hat loop) and on both machines and re-recorded that track back onto a new track (no plug-ins running). (On the root of c:)

I routed the headphone out of the Tascam back into the input. While I simply selected ‘Stereo Mix’ as the record source for the Santa Cruz.

(I only tested the Santa Cruz in the ‘office’ system. I am not prepared to muck around with it in the ‘studio’ computer)

Using Vegas 3 there were no issues whatsoever. When using the Tascam the recording of the first strike of the hat occurred at .006 (seconds) on both machines. Using the Santa Cruz the audio appeared at .002. (I repeated each of these tests three times and got the same results)

I then tested the Santa Cruz three times in Vegas 4. In three tests I got .122 .118 and .114

Using Vegas 4 with the Tascam (Windows Classic Wave Driver) on the office system the audio appeared at .120 .112 and .092.

Using Vegas 4 with the Tascam (Windows Classic Wave Driver) on the studio system the audio appeared at.084 .065 .069. I closed Vegas, reopened it and got .110 .081 .086.

Using Vegas 4 with the Tascam’s ASIO drivers also presented no problems on either system.

If I’ve done something wrong here please let me know.

Hope this helps.

These are interesting results.

Only problem with your method of testing is that we will never know if the problem is from the monitored source track on playback (where the track was imported to) or at the recorded track where the new track was recorded.

This is not the proper way to test track offsets. It is an appropriate way to check for monitoring latency.

Whether it is one or the other, it's pretty ugly.

D’oh!

I’m really only an interested observer here, always record Tascam ASIO myself.

So what would constitute a ‘proper’ test?

Hey Weevil,

Very good question and I'm glad you asked.

In order to properly test record latency, the "audio-to-be-recorded" would have to be an application's timeline generated event whose audio result did not output from or route through the application. This would define what the record latency is without the potential variable of playback or application output latency.

Record latency is hardware defined and should always be mathmatically absolute. Using the system's "Automatically detect and offset for hardware record latency" should always remain checked and if you use a "user defined" preset, each time you record, it should be absolute to the defined preset.

Hopefully, SF is all over this funkiness and will soon get to the bottom of this ugly problem.

It is a very befuddling issue that can be very difficult to define whether it exsists on the front end, at the back end or somewhere in between.

Hey Doc,

Unless you are using RAID, IDE/ATA addresses 1 device at a time. Although these addressing requests are very small and quite snappy, addresssing outside your boot disk requires an additional addressing request on both send and return. Partitions are viewed like different hard drives with different addresses, ... hence, the same.

One thing to keep in mind is that addressing requests occur prior to your drive's ability to throughput.

It may be insignificant in most cases, but in my first experience with V4, it was significant enough to create some audio reproduction problems.

>>Unless you are using RAID, IDE/ATA addresses 1 device at a time. Although these addressing requests are very small and quite snappy, addresssing outside your boot disk requires an additional addressing request on both send and return. Partitions are viewed like different hard drives with different addresses, ... hence, the same.
One thing to keep in mind is that addressing requests occur prior to your drive's ability to throughput.<<

OK tmpro, this makes sense theoretically. But the fact remains that virtually EVERYTHING I've heard or read recommends having a separate data drive (not referring to RAID here). Are you suggesting that this is NOT the way to set-up a DAW and that I should use the same drive for everything (except backup of course)? Also this seems a bit risky. If this had been the case when my main drive failed (due to a bad ram strip) a few months ago, I would have lost everything I was working on - an entire day's worth of work (I only backup once per day when I'm shutting everything down). The failure resulted in zapping the drive completely. Anyway I'm both confused and curious and would love it if others would join in on this. Perhaps I (we) should start another thread about it?

Thanks,

drbam

I've always heard that it's best to have an application drive (C:) where the OS and apps are stored and run from and a audio drive (D:) to record to and playback from.
I do this now with a standard IDE C: drive and a RAIDed IDE D: drive with no problems at all.
bgc

It would really help if people could get their heads around the correct terminology for things, when describing problems.

The main offender is the fn 'L-word' - "Latency". People seem happy to blame it for, and describe every with it. Maybe a bit more thought as to the effect being described would reduce confusion and wrong tangents.

Try :
- Record offset
- record offset compensation
- uncompensated record offset
- loss of synchronisation between tracks

Yes, they are mostly latency-related, but blanketing everything that goes wrong as Latency, really smudges things.

geoff

Yes DrBam, it was a theory on my part. I was actually running my machine precisely the way you've been running yours and had issues as I specified earlier in this thread.

The issues I experienced were resolved by following the previously described methods.

I've been running my systems this way flawlessly since. I also use GigaStudio 160 to its full potential with network accessed drives for over 400 gigs of uncompressed samples from my massive Giga sample library.

One thing to keep in mind though, I DO NOT track in Vegas .... I have only tracked with it in very limited way (for some mix-stage decision overdubbs and such). I track in different worlds. I prefer using MX-2424s with MX-View. At my place, I do this with outboard mic-pres and an O2R.

With RAID, you have a single drive address.