If Vegas ever gets ASIO then how...........

PipelineAudio wrote on 10/11/2002, 11:41 PM

I may be going back to Soundscape Mixtreme Cards as they seem to work just fine with no big fat fuss.

I really do need ASIO input monitoring feature we dont need to argue about why, lets just say it is a must. Apparently ASIO apps have a hard time dealing with multiple sound cards even if they're the same make and model.

How does ACID handle multiple sound cards in ASIO mode at the moment? Allegedly multiple Hammerfalls will work in Nuendo in ASIO while multiple mixtremes wont.

Comments

pwppch wrote on 10/12/2002, 12:25 AM

It is entirely dependent on the ASIO drivers. If the driver supports multiple cards, then the ASIO host can.

ASIO is a single "driver" at at time model. That means that only one ASIO "device" can be active at a time. A "device" can be 1 card ror 20 cards depending on the driver. So for the a N port card you would see a single ASIO "device" that has n/2 stereo pairs (assuming that the hardware has an even number of outputs). If the driver supports two cards, then you would see n/2 * 2 stereo pairs, etc, etc.

While it is conceivable that a host could stream to two ASIO devices at the same time, there is no mechanism to assure sample accurate sync between the two cards. Only the driver can control this, and if a driver talks to one card at at time, then the host cannot maintain sync like this. This is an architectual limitation of ASIO.

ASIO is also a very OS unfriendly API. That is, if one host is using the card in ASIO mode, it is VERY likely that any second app will be able to access the hardware while the first host is using it. In some cases, be prepare to crash your OS hard and fast. The ASIO sample driver code provided by Steinberg is very "casual" about testing for "am I busy or in use". A second app can actually wipe out the entire existance of a first app's connection to the driver with OUT telling the first app this has happened. The first app doesn't know it can't talk to the driver and death will occur very quickely.

Basically, ASIO doesn't like to share. This is part of the price that is paid to achieve the low latencies inherient to ASIO. Some hardware vendors have devised means to "split" a ASIO device into multiple devices so that two different hosts (or two instances of Vegas for example) could talk to the same hardware. Technically, these hosts are talking to the same device, but they can't talk to the same ports. Some vendors have even managed to make ASIO multi client - any number of apps can stream to the exact same outputs at anytime. The price you typically pay for this is increase latency and more PCI bus overhead. Any tricks that a particular vendor implements in this regard are unique and non standard though.

When you say ASIO "input monitoring", do you mean the ASIO 2.0 hardware based input monitoring or software monitoring? The former is a means for the ASIO 2.0 host to enable monitoring in the hardware. The later mode is where the host software performs the monitoring of inputs by streaming the input directly to the output.

Theoretically, ASIO 2.0 input monitoring will be zero latency. Host software monitoring will ALWAYS have latency as there is a delay between when the audio is recieved by the host and when the host can then route it back out. ASIO drivers have a mechanism to permit the host to know the exact amount of latency between inputs and outputs so that the host can adjust for this on recording. It doesn't make the latency go away, it just permits the host to account for it when recording.

Peter

PipelineAudio wrote on 10/12/2002, 12:45 AM

thanks for all that and let my digest it :)
I mean the input monitoring where it acts just as a tape recorder would:
in play, read the file and send it to the hardware output
in record send the hardware input STRAIGHT to the hardware output

so that would be the hardware one right?
but if I want to play my guitar thru amplitude then I need to use the software monitoring right ?...
oh well, I need to keep cubendo around for something

I dont understand why an mme driver cant do hardware input monitoring, "auto input " style. When you experiment it totally seems like it WANTS to :) almost

pwppch wrote on 10/12/2002, 1:15 PM

There are needs for both.

The hardware monitoring can be useful for the tape recorder model. It is also the lowest latency you can get. The problem is that routing in the hardware can be fixed or limited by the driver.

The playing through FX model does require the software method. There are also two cases for this.

- Record the raw audio, but monitor through the FX
- Record the processed audio

Personally, I would prefer the first case. If a plug is done correctly, then you can add the same FX to the raw file and achieve the exact same results as when you were monitoring through it. I also like to have the raw file incase I change my mind on a really good recording.

Best of both worlds: Save both.

Hardware monitor can be done with MME. It is not a function of the driver, but the hardware. MOTU, Frontier, and others all have a means to do hardware based monitoring externally to the driver. ASIO has an interface that permits the host to control this - to varying degrees - through the driver.

Doing software monitoring with MME is problematic to to latency and overhead. If the driver is native Wave, then yes it is very doable. The RME cards can achieve very low latencies in MME mode. If you are working with WDM based drivers, then the kmixer will add far to much overhead to achieve useable input monitoring in software.

Peter

PipelineAudio wrote on 10/12/2002, 1:45 PM

"- Record the raw audio, but monitor through the FX
- Record the processed audio

Personally, I would prefer the first case"

I agree 100% and for the reasons you stated...

AS for the MME thing, what I meant is...when I arm a track in vegas, my soundscape card and my RME card, both will send the input signal to the output...I dont THINK that it is going into the PC and then coming back out, it " feels " as if its a hardware thing...In order to check I split the signal going in and put one out of phase and it nearly cancels.

so it seems that even in MME, when I arm a track, I hear the input. When I play with it armed, I still hear the input, which is the problem...if there were a way to force it to playback disc when aremd until the punch in point that would be nearly case closed.

pwppch wrote on 10/13/2002, 11:32 AM

Correct. The input is not being monitored by Vegas. The hardware/driver does this.

With MME, there is not control from the host. However the driver does the input monitoring is how works.

Q: Why is it a problem to hear the input when playing while only armed?

Peter

PipelineAudio wrote on 10/13/2002, 12:23 PM

Some Traditional clients dont like it, at all! To me, its kinda nice sometimes and not so nice sometimes. In hardware that has a " monitoring" app built in you can " mix input with output" or whatever and then you can ALWAYS hear input no matter what but...

With the 9652 I have, if you send input one to output one, by using another output buss in vegas so that it feels like a regular multitrack, when it is armed it will NOT play back whats on the disc, so that doesnt work anyway.
The way I have to do it now, is send ALL tracks out of the spdif out, while recording in the other chanels.

PipelineAudio wrote on 10/14/2002, 12:52 PM

I guess what its getting down to is, RME is alleged to have multi card support that works in ASIO apps, while The mixtreme's multicard support for asio is shaky