Hi Peter
Could you please post this fix when it happens,To get around this I
monitor the L/R mix on the or Mackie D8B and on the 32.8 buss,
George Ware

Peter Haller wrote:
>> >> >>This is fixed, and will appear in Vegas Video/Audio. (Not sure about >>the next beta.) >> >>The problem is not a new wave driver standard - WDM is not a wave >>driver model. WDM permits the OS in 98 and Win2000 to emulated the >>Wave API so that application designed around the Wave API can >>function with WDM only drivers. Currently there are not a lot of WDM >>drivers available other than for your standard consumder fare. >> >>As far as what the MOTU drivers do/don't do, they are technically >>Wave drivers. Their implementation when doing SRP is somewhat >>different because of the way the hardware does DMA. It also related >>to the way the layer the Wave driver implementation upon a fixed i/o >>model in the kernel. >> >>Regardless, there is a work around for Vegas 1.0 that involves >>changing a cfg file. This is documented by MOTU. It does have a side >>effect of loss of audio at the beggining of the recorded track. >> >>The solution that we will be shipping will solve the problem >>correctly. >> >>Peter >> >> >>Lord Vader wrote: >>>>I've seen some confusion regarding if Vegas works with the >>>>MOTU family of interfaces. I have a MOTU 1224 myself and >>>>have done some extensive research. Here goes... >>>> >>>>Vegas does work with MOTU - sort of. The latency problem >>>>referred to by many users is syncronization problems >>>>between what comes out what goes in and. In reality this >>>>means that if you're doing an overdub while listening to a >>>>previously recorded track, your new track will be behind >>>>the first. >>>> >>>>To test this, create a click track and loop it in Vegas. >>>>Send it to an output on your MOTU interface, patch that >>>>output to an input, and record that. Now look at (or listen >>>>to) the waveforms - the newly recorded will lag behind the >>>>original. And I'm not talking about some 1ms A/D D/A >>>>latency, we're in the order of a whopping 200msec(!). >>>> >>>>The lag is proportional to the buffer size the MOTU drivers >>>>are set up to use. The bigger the buffer, the longer the >>>>lag. I expect the problem to be the same with all MOTU >>>>interfaces, since the PCI-324 driver are the same. >>>> >>>>I've been in contact with support on both sides. >>>>SonicFoundry claims this is a problem with the MOTU >>>>drivers, MOTU claims that Vegas should have an offset >>>>selector. BTW, the "position value" sliders in Vegas does >>>>not work. >>>> >>>>Actually, they are both right. Vegas assumes drivers be >>>>compliant to newer specs of the wave interface, MOTU >>>>implements an old wave interface which doesn't say anything >>>>about sync (I know, I read it). >>>> >>>>Ideally, MOTU should write newer WDM style wave drivers, >>>>and Vegas should implement an offset. Until either is done >>>>it will _not_ work. There is _no_ setting in Vegas, MOTU or >>>>the OS that will make this work. Believe me. >>>> >>>>I'm working on a third party fix myself to intercept and >>>>patch either Vegas or the MOTU driver. I will post again >>>>here if I get it to work. Until then, steer clear of the >>>>combination if you plan on doing overdubs, or just plain >>>>like to get the data synced for editing purposes. >>>> >>>>Hope this helps. >>>>

Hey George...

I think we may be talking about two different things.(?)

I don't see how using an external desk could fix this problem.

As far as posting the fix, the fix will be part of the Vegas
Video/Audio release. I don't know if there are any plans for an
interim 1.0x update.

Peter




George Ware wrote:
>>Hi Peter
>>Could you please post this fix when it happens,To get around this I
>>monitor the L/R mix on the or Mackie D8B and on the 32.8 buss,
>>George Ware
>>
>>Peter Haller wrote:
>>>> >>>> >>>>This is fixed, and will appear in Vegas Video/Audio. (Not sure >>about >>>>the next beta.) >>>> >>>>The problem is not a new wave driver standard - WDM is not a wave >>>>driver model. WDM permits the OS in 98 and Win2000 to emulated the >>>>Wave API so that application designed around the Wave API can >>>>function with WDM only drivers. Currently there are not a lot of >>WDM >>>>drivers available other than for your standard consumder fare. >>>> >>>>As far as what the MOTU drivers do/don't do, they are technically >>>>Wave drivers. Their implementation when doing SRP is somewhat >>>>different because of the way the hardware does DMA. It also related >>>>to the way the layer the Wave driver implementation upon a fixed >>i/o >>>>model in the kernel. >>>> >>>>Regardless, there is a work around for Vegas 1.0 that involves >>>>changing a cfg file. This is documented by MOTU. It does have a >>side >>>>effect of loss of audio at the beggining of the recorded track. >>>> >>>>The solution that we will be shipping will solve the problem >>>>correctly. >>>> >>>>Peter >>>> >>>> >>>>Lord Vader wrote: >>>>>>I've seen some confusion regarding if Vegas works with the >>>>>>MOTU family of interfaces. I have a MOTU 1224 myself and >>>>>>have done some extensive research. Here goes... >>>>>> >>>>>>Vegas does work with MOTU - sort of. The latency problem >>>>>>referred to by many users is syncronization problems >>>>>>between what comes out what goes in and. In reality this >>>>>>means that if you're doing an overdub while listening to a >>>>>>previously recorded track, your new track will be behind >>>>>>the first. >>>>>> >>>>>>To test this, create a click track and loop it in Vegas. >>>>>>Send it to an output on your MOTU interface, patch that >>>>>>output to an input, and record that. Now look at (or listen >>>>>>to) the waveforms - the newly recorded will lag behind the >>>>>>original. And I'm not talking about some 1ms A/D D/A >>>>>>latency, we're in the order of a whopping 200msec(!). >>>>>> >>>>>>The lag is proportional to the buffer size the MOTU drivers >>>>>>are set up to use. The bigger the buffer, the longer the >>>>>>lag. I expect the problem to be the same with all MOTU >>>>>>interfaces, since the PCI-324 driver are the same. >>>>>> >>>>>>I've been in contact with support on both sides. >>>>>>SonicFoundry claims this is a problem with the MOTU >>>>>>drivers, MOTU claims that Vegas should have an offset >>>>>>selector. BTW, the "position value" sliders in Vegas does >>>>>>not work. >>>>>> >>>>>>Actually, they are both right. Vegas assumes drivers be >>>>>>compliant to newer specs of the wave interface, MOTU >>>>>>implements an old wave interface which doesn't say anything >>>>>>about sync (I know, I read it). >>>>>> >>>>>>Ideally, MOTU should write newer WDM style wave drivers, >>>>>>and Vegas should implement an offset. Until either is done >>>>>>it will _not_ work. There is _no_ setting in Vegas, MOTU or >>>>>>the OS that will make this work. Believe me. >>>>>> >>>>>>I'm working on a third party fix myself to intercept and >>>>>>patch either Vegas or the MOTU driver. I will post again >>>>>>here if I get it to work. Until then, steer clear of the >>>>>>combination if you plan on doing overdubs, or just plain >>>>>>like to get the data synced for editing purposes. >>>>>> >>>>>>Hope this helps. >>>>>>

PLEASE POST THIS AS A PATCH OR UPDATE for 1.0!!! For those of us who
weren't warned about this problem six months ago (even after speaking
with SF beforehand) and decided on MOTU/VEGAS configurations, I
suggest that the ONLY fair course of action on SF's part would be to
release a patch...A FREE patch!

Overdubbing is a "core" function that should work with ANY
interface...Fact is, there was no warning given to me about this
problem, which led to my MOTU decision...It shouldn't cost me $99 to
fix this basic problem.

I would also think that this fix would be a fairly urgent
priority...There are a good many MOTU users out here who can't work
properly.

Thanks.

BTW...Sound Forge 4.5 has the same, extraordinary latency
problems...I usually end up adding 3 seconds of silence to the
beginning of a stereo file just to allow lockup before the first
downbeat...I hope the "fix" will apply to all Sound Forge products
with MOTU.



Peter Haller wrote:
>>As far as posting the fix, the fix will be part of the Vegas
>>Video/Audio release. I don't know if there are any plans for an
>>interim 1.0x update.
>>
>>Peter

There will be no futher updates to 1.0. This fix will only be
available in the paid upgrade to Vegas Audio 2.0.

While this may seem unfair, this is the life cycle of software. We
have in the past provided free interm fixes to bugs and features.
Eventually as the products move to a new release with significant new
features, we have to move to a paid upgrade.

Vegas Audio 2.0 has significant new features in addition to fixes
such as this. I think that you will find that the upgrade will
provide you with more than just this fix.

As far as how Forge is effected by this, the problem is specifically
related to recording while playing back. Since Forge can't do this,
the problem you are experiancing is different. If you could explain
the problem you are having with Forge and the MOTU in more detail, I
will look into it.

Thanks
Peter



David wrote:
>>PLEASE POST THIS AS A PATCH OR UPDATE for 1.0!!! For those of us
who
>>weren't warned about this problem six months ago (even after
speaking
>>with SF beforehand) and decided on MOTU/VEGAS configurations, I
>>suggest that the ONLY fair course of action on SF's part would be
to
>>release a patch...A FREE patch!
>>
>>Overdubbing is a "core" function that should work with ANY
>>interface...Fact is, there was no warning given to me about this
>>problem, which led to my MOTU decision...It shouldn't cost me $99
to
>>fix this basic problem.
>>
>>I would also think that this fix would be a fairly urgent
>>priority...There are a good many MOTU users out here who can't work
>>properly.
>>
>>Thanks.
>>
>>BTW...Sound Forge 4.5 has the same, extraordinary latency
>>problems...I usually end up adding 3 seconds of silence to the
>>beginning of a stereo file just to allow lockup before the first
>>downbeat...I hope the "fix" will apply to all Sound Forge products
>>with MOTU.
>>
>>
>>
>>Peter Haller wrote:
>>>>As far as posting the fix, the fix will be part of the Vegas
>>>>Video/Audio release. I don't know if there are any plans for an
>>>>interim 1.0x update.
>>>>
>>>>Peter
>>

>>
>>As far as how Forge is effected by this, the problem is
specifically
>>related to recording while playing back. Since Forge can't do this,
>>the problem you are experiancing is different. If you could explain
>>the problem you are having with Forge and the MOTU in more detail,
I
>>will look into it.
>>
>>Thanks
>>Peter

Hi Peter,

Sorry to hear there will be no patches to Vegas 1.0...That was a very
short life-cycle IMHO...Oh well, it's only $$$.

As for Sound Forge 4.5...The latency exists on all 44.1-16bit stereo
files of 3-5 minute length...I generally have to add 2-3 seconds of
silence to the head of the wavefile to allow for enough buffering to
play out the first bit of audio...The MOTU is set to clock to 1224
internal.

SPECS:

PIII 733 w/256MB RAM (133FSB VIA Chipset), 7200rpm ATA66 HD, MOTU
1224/PCI-324 interface.

Not sure what could be going on here...The buffering in SF is set to
its detent...It doesn't feel good when a $1500 doesn't work as well
as an SB16! ;-)

Any help would be appreciated.

David

Peter Haller wrote:
>> >> >> >>Regardless, there is a work around for Vegas 1.0 that involves >>changing a cfg file. This is documented by MOTU. It does have a side >>effect of loss of audio at the beggining of the recorded track. >> Peter/anyone, I'm using a MOTU 2408mkII and Vegas Pro. Will buy the upgrade when available, but would like to try this work around in the meantime. You say: "Documented by MOTU?" Where? Could you document it here? I think all the other MOTU users would appreciate it. When I search this forum for "MOTU", I get tons of messages, but none have any solutions that I can use now. Thanks, John Q.

Sure, here is the work around:

The work around is as follows:

In the Windows installation directory, MOTU places the file

motup324.cfg.

This is a text file that contains by default:

[Compatibility]
DDHELP.EXE=17
CWPA.EXE=392

The user needs to add the line

VEGAS.EXE=392

This will force the MOTU hardware to deal with record/playback offset
latency in the hardware. The side effect of this is to introduce a
buffer of silence at the beginning of the recorded material.

Let me know how this works for you.

Thanks
Peter



John Quarantillo wrote:
>>
>>
>>Peter Haller wrote:
>>>> >>>> >>>> >>>>Regardless, there is a work around for Vegas 1.0 that involves >>>>changing a cfg file. This is documented by MOTU. It does have a >>side >>>>effect of loss of audio at the beggining of the recorded track. >>>> >> >>Peter/anyone, >> >>I'm using a MOTU 2408mkII and Vegas Pro. Will buy the upgrade when >>available, but would like to try this work around in the meantime. >>You say: >>"Documented by MOTU?" Where? >> >>Could you document it here? I think all the other MOTU users would >>appreciate it. When I search this forum for "MOTU", I get tons of >>messages, but none have any solutions that I can use now. >> >>Thanks, >>John Q.

Peter,
Thanks for the quick reply. Can you elaborate on the 'buffer of
silence' introduced? Does this render punch in/out useless?

Thanks,

John Q.

Peter Haller wrote:
>>Sure, here is the work around:
>>This will force the MOTU hardware to deal with record/playback offset >>latency in the hardware. The side effect of this is to introduce a >>buffer of silence at the beginning of the recorded material. >> >>Let me know how this works for you. >> >>Thanks >>Peter

Basically the problem is that the MOTU hardware has a DMA buffer
situation that forces the first buffer or portion of it to be filled
with silence. This is what causes the offset problem with out the fix
below. When the cgf file is modified as described, the driver
attempts to offset the DMA buffers before they are returned. This can
cause a loss of samples.

As far as the punch in goes. No, it actually wont cause a problem if
you are recording into an event in Vegas and you start playback
before the event. When Vegas is recording into an event, we are
actually recording before the event as well. We only show you the
events worth of data.

If you are not recording into an event and just hit the record
button, then you should start your record position slightly before
the point you want to "record" at. This way you wont have the brief
silence that will be recorded (or not recorded).

Make sense?

Peter


John Quarantillo wrote:
>>Peter,
>>Thanks for the quick reply. Can you elaborate on the 'buffer of
>>silence' introduced? Does this render punch in/out useless?
>>
>>Thanks,
>>
>>John Q.
>>
>>Peter Haller wrote:
>>>>Sure, here is the work around:
>> >>>>This will force the MOTU hardware to deal with record/playback >>offset >>>>latency in the hardware. The side effect of this is to introduce a >>>>buffer of silence at the beginning of the recorded material. >>>> >>>>Let me know how this works for you. >>>> >>>>Thanks >>>>Peter >>