The PARIS Forums


Home » The PARIS Forums » PARIS: Main » PCI latency......a whole 'nuther can of worms
PCI latency......a whole 'nuther can of worms [message #64125] Thu, 02 February 2006 23:27 Go to next message
Deej [1] is currently offline  Deej [1]   UNITED STATES
Messages: 2149
Registered: January 2006
Senior Member
I'm just having such a gret time in *nativeville* these days. So much to
learn. I've been getting crackling inmy audio when streaming tracks from
Cubase to Paris when using large numbers of UAD-1 plugins. Well, come to
find out, there's more fun to be had in tweakville......

Here's some info on PCI latency.

http://www.soundonsound.com/sos/Oct04/articles/pcnotes.htm

http://www.uaudio.com/webzine/2005/june/index5.html

http://mark-knutson.com/t3/

http://downloads.guru3d.com/download.php?det=951

From what I can determine from reading a few threads about this, PCI latency
is the amount of "wait" time PCI is allocated to communicate with any given
peripheral. A high PCI Latency setting takes more PCI bus time than another
device with a lower setting. Normally, the PCI Latency Timer is set to 32
cycles. This means the active PCI device has to complete its transactions
within 32 clock cycles or hand it over to the next PCI device. As you can
see, a device, like a video card which has a setting of 248 essentially
"hogs" the PCI Bus.

PCI latency timers are a mechanism for PCI bus-mastering devices to share
the PCI bus fairly. A device such as the RME 9652 gains bus ownership and
the clock counts down based on the latency setting. In our case the RME
9652 specifies a clock count of 255 (unlike most devices which accept the
default count set equally for other devices on the the PCI bus). You might
want to check the default PCI latency for the MADI.

In most cases the healthy level for setting this is around 32-64, but can
sometimes be higher for various sound cards or video cards reaching to the
upward amounts of 128.

The 255 requested by RME HDSP cards seems to be wayyyyyy on the high side.
(which is in fact the maximum value available). I understand that setting
this value too low can can interrupt transfers unnecessarily and hurt the
9652's performance, but setting the value too high can cause other devices
to wait longer than they should have too, therefore overflowing their
buffers. this can be really problematic with some network cards (and I'm
using a Marvel onboard LAN so I'll have to check this further.

I used the Doubledawg PCI latency utility to tweak my PCI latency settings
a bit. I dropped the latency of the Matrox G450 to 32, switched my UAD-1
cards from 128 to 64 in the UAD-1 control panel and backed the latency of my
HDSP 9652 cards from 255 to 248. This, plus changing to buffers in my RME
control panel to 2048 has solved my problem with *crackling* of the audio
with 15 UAD-1 plugins using 40% of the available CPU resources of the cards.
Any more than this and the crackling returns so this is definitely an issue
with the UAD-1 cards. Since my UAD and RME cards are in a Magma, tweaking
the settings for the PCI-PCI bridge (perhaps increasing them in this case
while lowering the latency timing on the cards themselves) might be a fix.
It's going to be interesting......and as I suspected.......it never ends.

;o)
Re: PCI latency......a whole 'nuther can of worms [message #64128 is a reply to message #64125] Fri, 03 February 2006 02:04 Go to previous messageGo to next message
rick is currently offline  rick   UNITED STATES
Messages: 1976
Registered: February 2006
Senior Member
well that sure would explain the random digi noise i was getting in
logic but now that it's crashing if you breathe around it i'll deal
with that issue later.

On Fri, 3 Feb 2006 00:27:35 -0700, "DJ"
<animix_spam-this-ahole_@animas.net> wrote:

>I'm just having such a gret time in *nativeville* these days. So much to
>learn. I've been getting crackling inmy audio when streaming tracks from
>Cubase to Paris when using large numbers of UAD-1 plugins. Well, come to
>find out, there's more fun to be had in tweakville......
>
>Here's some info on PCI latency.
>
>http://www.soundonsound.com/sos/Oct04/articles/pcnotes.htm
>
>http://www.uaudio.com/webzine/2005/june/index5.html
>
>http://mark-knutson.com/t3/
>
>http://downloads.guru3d.com/download.php?det=951
>
>From what I can determine from reading a few threads about this, PCI latency
>is the amount of "wait" time PCI is allocated to communicate with any given
>peripheral. A high PCI Latency setting takes more PCI bus time than another
>device with a lower setting. Normally, the PCI Latency Timer is set to 32
>cycles. This means the active PCI device has to complete its transactions
>within 32 clock cycles or hand it over to the next PCI device. As you can
>see, a device, like a video card which has a setting of 248 essentially
>"hogs" the PCI Bus.
>
>PCI latency timers are a mechanism for PCI bus-mastering devices to share
>the PCI bus fairly. A device such as the RME 9652 gains bus ownership and
>the clock counts down based on the latency setting. In our case the RME
>9652 specifies a clock count of 255 (unlike most devices which accept the
>default count set equally for other devices on the the PCI bus). You might
>want to check the default PCI latency for the MADI.
>
>In most cases the healthy level for setting this is around 32-64, but can
>sometimes be higher for various sound cards or video cards reaching to the
>upward amounts of 128.
>
>The 255 requested by RME HDSP cards seems to be wayyyyyy on the high side.
>(which is in fact the maximum value available). I understand that setting
>this value too low can can interrupt transfers unnecessarily and hurt the
>9652's performance, but setting the value too high can cause other devices
>to wait longer than they should have too, therefore overflowing their
>buffers. this can be really problematic with some network cards (and I'm
>using a Marvel onboard LAN so I'll have to check this further.
>
>I used the Doubledawg PCI latency utility to tweak my PCI latency settings
>a bit. I dropped the latency of the Matrox G450 to 32, switched my UAD-1
>cards from 128 to 64 in the UAD-1 control panel and backed the latency of my
>HDSP 9652 cards from 255 to 248. This, plus changing to buffers in my RME
>control panel to 2048 has solved my problem with *crackling* of the audio
>with 15 UAD-1 plugins using 40% of the available CPU resources of the cards.
>Any more than this and the crackling returns so this is definitely an issue
>with the UAD-1 cards. Since my UAD and RME cards are in a Magma, tweaking
>the settings for the PCI-PCI bridge (perhaps increasing them in this case
>while lowering the latency timing on the cards themselves) might be a fix.
>It's going to be interesting......and as I suspected.......it never ends.
>
>;o)
>
>
Re: PCI latency......a whole 'nuther can of worms [message #64133 is a reply to message #64125] Fri, 03 February 2006 09:04 Go to previous messageGo to next message
gene lennon is currently offline  gene lennon
Messages: 565
Registered: July 2006
Senior Member
Many people with multiple UAD-1 cards in Magma systems have reported similar
issues. Magma is planning to release a PCI Express converter card that will
allow your system to run from a PCI-E slot in the near future. This, combined
with tweaking PCI latency settings, may help. I think it’s time for a new
card from UA.
g


"DJ" <animix_spam-this-ahole_@animas.net> wrote:
>I'm just having such a gret time in *nativeville* these days. So much to
>learn. I've been getting crackling inmy audio when streaming tracks from
>Cubase to Paris when using large numbers of UAD-1 plugins. Well, come to
>find out, there's more fun to be had in tweakville......
>
>Here's some info on PCI latency.
>
>http://www.soundonsound.com/sos/Oct04/articles/pcnotes.htm
>
>http://www.uaudio.com/webzine/2005/june/index5.html
>
>http://mark-knutson.com/t3/
>
>http://downloads.guru3d.com/download.php?det=951
>
>From what I can determine from reading a few threads about this, PCI latency
>is the amount of "wait" time PCI is allocated to communicate with any given
>peripheral. A high PCI Latency setting takes more PCI bus time than another
>device with a lower setting. Normally, the PCI Latency Timer is set to 32
>cycles. This means the active PCI device has to complete its transactions
>within 32 clock cycles or hand it over to the next PCI device. As you can
>see, a device, like a video card which has a setting of 248 essentially
>"hogs" the PCI Bus.
>
>PCI latency timers are a mechanism for PCI bus-mastering devices to share
>the PCI bus fairly. A device such as the RME 9652 gains bus ownership and
>the clock counts down based on the latency setting. In our case the RME
>9652 specifies a clock count of 255 (unlike most devices which accept the
>default count set equally for other devices on the the PCI bus). You might
>want to check the default PCI latency for the MADI.
>
>In most cases the healthy level for setting this is around 32-64, but can
>sometimes be higher for various sound cards or video cards reaching to the
>upward amounts of 128.
>
>The 255 requested by RME HDSP cards seems to be wayyyyyy on the high side.
>(which is in fact the maximum value available). I understand that setting
>this value too low can can interrupt transfers unnecessarily and hurt the
>9652's performance, but setting the value too high can cause other devices
>to wait longer than they should have too, therefore overflowing their
>buffers. this can be really problematic with some network cards (and I'm
>using a Marvel onboard LAN so I'll have to check this further.
>
>I used the Doubledawg PCI latency utility to tweak my PCI latency settings
>a bit. I dropped the latency of the Matrox G450 to 32, switched my UAD-1
>cards from 128 to 64 in the UAD-1 control panel and backed the latency of
my
>HDSP 9652 cards from 255 to 248. This, plus changing to buffers in my RME
>control panel to 2048 has solved my problem with *crackling* of the audio
>with 15 UAD-1 plugins using 40% of the available CPU resources of the cards.
>Any more than this and the crackling returns so this is definitely an issue
>with the UAD-1 cards. Since my UAD and RME cards are in a Magma, tweaking
>the settings for the PCI-PCI bridge (perhaps increasing them in this case
>while lowering the latency timing on the cards themselves) might be a fix.
>It's going to be interesting......and as I suspected.......it never ends.
>
>;o)
>
>
>
Re: PCI latency......a whole 'nuther can of worms [message #64135 is a reply to message #64133] Fri, 03 February 2006 08:24 Go to previous messageGo to next message
Deej [1] is currently offline  Deej [1]   UNITED STATES
Messages: 2149
Registered: January 2006
Senior Member
One possible solution to this would be Systemlink, I think. Use the acards
in a separate DAW to minimize the hit to the PCI bus of the workstation
performing playback......at least in theory.

I'm pretty much SOL once my UAD resources exceed 40%, no matter what PCI
latency I use.......and I've got another DAW just sitting here.......and AMD
XP 3000 CPU with 2G PC2700 DDR nd a system drive. All I need is a case, PSU,
a sound card and VStack. I have configured this machine in the past with 3 x
UAD-1 cards in the PCI slots without issue. Since there ar 6 PCI slots and
one of them was holding my Magma host cards, I doubt if I would nave much
problem running 4 x UAD cards. I just wonder if the PCI latency would be an
issue on this machine under heavy plugin loads also, even though it wouldn't
be hosting a playback application(unlessVstack could be considered a
playback app)


"gene lennon" <glennon@NOSPmyrealbox.com> wrote in message
news:43e37f0c$1@linux...
>
> Many people with multiple UAD-1 cards in Magma systems have reported
similar
> issues. Magma is planning to release a PCI Express converter card that
will
> allow your system to run from a PCI-E slot in the near future. This,
combined
> with tweaking PCI latency settings, may help. I think it's time for a new
> card from UA.
> g
>
>
> "DJ" <animix_spam-this-ahole_@animas.net> wrote:
> >I'm just having such a gret time in *nativeville* these days. So much to
> >learn. I've been getting crackling inmy audio when streaming tracks from
> >Cubase to Paris when using large numbers of UAD-1 plugins. Well, come to
> >find out, there's more fun to be had in tweakville......
> >
> >Here's some info on PCI latency.
> >
> >http://www.soundonsound.com/sos/Oct04/articles/pcnotes.htm
> >
> >http://www.uaudio.com/webzine/2005/june/index5.html
> >
> >http://mark-knutson.com/t3/
> >
> >http://downloads.guru3d.com/download.php?det=951
> >
> >From what I can determine from reading a few threads about this, PCI
latency
> >is the amount of "wait" time PCI is allocated to communicate with any
given
> >peripheral. A high PCI Latency setting takes more PCI bus time than
another
> >device with a lower setting. Normally, the PCI Latency Timer is set to 32
> >cycles. This means the active PCI device has to complete its transactions
> >within 32 clock cycles or hand it over to the next PCI device. As you can
> >see, a device, like a video card which has a setting of 248 essentially
> >"hogs" the PCI Bus.
> >
> >PCI latency timers are a mechanism for PCI bus-mastering devices to share
> >the PCI bus fairly. A device such as the RME 9652 gains bus ownership
and
> >the clock counts down based on the latency setting. In our case the RME
> >9652 specifies a clock count of 255 (unlike most devices which accept the
> >default count set equally for other devices on the the PCI bus). You
might
> >want to check the default PCI latency for the MADI.
> >
> >In most cases the healthy level for setting this is around 32-64, but can
> >sometimes be higher for various sound cards or video cards reaching to
the
> >upward amounts of 128.
> >
> >The 255 requested by RME HDSP cards seems to be wayyyyyy on the high
side.
> >(which is in fact the maximum value available). I understand that
setting
> >this value too low can can interrupt transfers unnecessarily and hurt the
> >9652's performance, but setting the value too high can cause other
devices
> >to wait longer than they should have too, therefore overflowing their
> >buffers. this can be really problematic with some network cards (and I'm
> >using a Marvel onboard LAN so I'll have to check this further.
> >
> >I used the Doubledawg PCI latency utility to tweak my PCI latency
settings
> >a bit. I dropped the latency of the Matrox G450 to 32, switched my UAD-1
> >cards from 128 to 64 in the UAD-1 control panel and backed the latency of
> my
> >HDSP 9652 cards from 255 to 248. This, plus changing to buffers in my RME
> >control panel to 2048 has solved my problem with *crackling* of the audio
> >with 15 UAD-1 plugins using 40% of the available CPU resources of the
cards.
> >Any more than this and the crackling returns so this is definitely an
issue
> >with the UAD-1 cards. Since my UAD and RME cards are in a Magma, tweaking
> >the settings for the PCI-PCI bridge (perhaps increasing them in this case
> >while lowering the latency timing on the cards themselves) might be a
fix.
> >It's going to be interesting......and as I suspected.......it never ends.
> >
> >;o)
> >
> >
> >
Re: PCI latency......a whole 'nuther can of worms [message #64136 is a reply to message #64135] Fri, 03 February 2006 10:39 Go to previous messageGo to next message
gene lennon is currently offline  gene lennon
Messages: 565
Registered: July 2006
Senior Member
“All I need is a case, PSU,
a sound card and Vstack”

If you are referring to Steinberg’s V-Stack, you will need a different solution.

V-Stack has no “Audio in”.
Otherwise it sounds like a workable solution. Very DJ-ish.
g


"DJ" <animix_spam-this-ahole_@animas.net> wrote:
>One possible solution to this would be Systemlink, I think. Use the acards
>in a separate DAW to minimize the hit to the PCI bus of the workstation
>performing playback......at least in theory.
>
>I'm pretty much SOL once my UAD resources exceed 40%, no matter what PCI
>latency I use.......and I've got another DAW just sitting here.......and
AMD
>XP 3000 CPU with 2G PC2700 DDR nd a system drive. All I need is a case,
PSU,
>a sound card and VStack. I have configured this machine in the past with
3 x
>UAD-1 cards in the PCI slots without issue. Since there ar 6 PCI slots and
>one of them was holding my Magma host cards, I doubt if I would nave much
>problem running 4 x UAD cards. I just wonder if the PCI latency would be
an
>issue on this machine under heavy plugin loads also, even though it wouldn't
>be hosting a playback application(unlessVstack could be considered a
>playback app)
>
Re: PCI latency......a whole 'nuther can of worms [message #64142 is a reply to message #64136] Fri, 03 February 2006 12:41 Go to previous messageGo to next message
Deej [1] is currently offline  Deej [1]   UNITED STATES
Messages: 2149
Registered: January 2006
Senior Member
Hmmmm.....I see what you mean. Seems I've got something here that is a bit
better (and beyond) systemlink anyway. Theoretically, I could split off one
of my HDSP cards and a couple of the UAD-1 cards, install them on my second
computer, install Cubase SE (or any other PC compatible audio app which has
PDC) on the second computer, use my network to transfer some tracks (like
the drum submix and bass instruments) to one computer and the rest of the
audio to the other computer, run ADAT sync cables from ADAT cards in my MECs
to the audio cards in the two different comps, then apply the UAD-1 FX to
the tracks on both computers which are controlled by ADAT sync from the
Paris transport. this would be superior to systemlink, most likely. the
downside to this is that during a lot of my mix process, I am just playing
back using the Cubase SX transport, streaming the audio via lightpipe
feeding Paris with the monitor bus in Paris feeding my DAC-1 . reference
system. I only use the Paris transport to slave the Cubase DAW during the
last phase of the mix when I'm automating tracks and panning in Paris and
then subsequently boundcing down using the Paris mix bus. In order to have
both computers running in sync *without* being controlled by Paris ADAT
sync, (which is most of the time I'm mixing) I would need to use a
Systemlink compatible Steiny product aand have a spdif connection between
the two Steiny machines. I guess, after I finish tracking in Paris, sending
and the tracks from Paris via LAN to WL5 on the Cubase DAW for batch
conversion to .wav, I could then further transfer them from the primary
Cubase DAW to the secondary Cubase DAW via LAN, then get a couple of my
UAD-1 cards authorized for the second DAW.

This shouldn't take over a couple of weeks to set up and stabilize and would
involve mixing on three x DAWs plus another comp running as a standalone FX
processor instead of just two DAWs plus another one running as a standalone
FX processor.

Hell man .......piece of cake.

;o)

(actually, I'm not sure, but I think that I may not be quite crazy enough to
want to deal with this much crap)

"gene lennon" <glennon@NOSPmyrealbox.com> wrote in message
news:43e3954e$1@linux...
>
> "All I need is a case, PSU,
> a sound card and Vstack"
>
> If you are referring to Steinberg's V-Stack, you will need a different
solution.
>
> V-Stack has no "Audio in".
> Otherwise it sounds like a workable solution. Very DJ-ish.
> g
>
>
> "DJ" <animix_spam-this-ahole_@animas.net> wrote:
> >One possible solution to this would be Systemlink, I think. Use the
acards
> >in a separate DAW to minimize the hit to the PCI bus of the workstation
> >performing playback......at least in theory.
> >
> >I'm pretty much SOL once my UAD resources exceed 40%, no matter what PCI
> >latency I use.......and I've got another DAW just sitting here.......and
> AMD
> >XP 3000 CPU with 2G PC2700 DDR nd a system drive. All I need is a case,
> PSU,
> >a sound card and VStack. I have configured this machine in the past with
> 3 x
> >UAD-1 cards in the PCI slots without issue. Since there ar 6 PCI slots
and
> >one of them was holding my Magma host cards, I doubt if I would nave much
> >problem running 4 x UAD cards. I just wonder if the PCI latency would be
> an
> >issue on this machine under heavy plugin loads also, even though it
wouldn't
> >be hosting a playback application(unlessVstack could be considered a
> >playback app)
> >
>
Re: PCI latency......a whole 'nuther can of worms [message #64147 is a reply to message #64142] Fri, 03 February 2006 17:13 Go to previous messageGo to next message
gene lennon is currently offline  gene lennon
Messages: 565
Registered: July 2006
Senior Member
Not sure if you are joking or going crazy!

Install UAD-1 cards on second computer.
Use any app like Cubase to host the plugins.
Send audio back and forth with ADAT optical.
Link Soundcards with ADAT Clock.
Done.
No MIDI, No ADAT Sync, No systemlink, etc.


"DJ" <animix_spam-this-ahole_@animas.net> wrote:
>Hmmmm.....I see what you mean. Seems I've got something here that is a bit
>better (and beyond) systemlink anyway. Theoretically, I could split off
one
>of my HDSP cards and a couple of the UAD-1 cards, install them on my second
>computer, install Cubase SE (or any other PC compatible audio app which
has
>PDC) on the second computer, use my network to transfer some tracks (like
>the drum submix and bass instruments) to one computer and the rest of the
>audio to the other computer, run ADAT sync cables from ADAT cards in my
MECs
>to the audio cards in the two different comps, then apply the UAD-1 FX to
>the tracks on both computers which are controlled by ADAT sync from the
>Paris transport. this would be superior to systemlink, most likely. the
>downside to this is that during a lot of my mix process, I am just playing
>back using the Cubase SX transport, streaming the audio via lightpipe
>feeding Paris with the monitor bus in Paris feeding my DAC-1 . reference
>system. I only use the Paris transport to slave the Cubase DAW during the
>last phase of the mix when I'm automating tracks and panning in Paris and
>then subsequently boundcing down using the Paris mix bus. In order to have
>both computers running in sync *without* being controlled by Paris ADAT
>sync, (which is most of the time I'm mixing) I would need to use a
>Systemlink compatible Steiny product aand have a spdif connection between
>the two Steiny machines. I guess, after I finish tracking in Paris, sending
>and the tracks from Paris via LAN to WL5 on the Cubase DAW for batch
>conversion to .wav, I could then further transfer them from the primary
>Cubase DAW to the secondary Cubase DAW via LAN, then get a couple of my
>UAD-1 cards authorized for the second DAW.
>
>This shouldn't take over a couple of weeks to set up and stabilize and would
>involve mixing on three x DAWs plus another comp running as a standalone
FX
>processor instead of just two DAWs plus another one running as a standalone
>FX processor.
>
>Hell man .......piece of cake.
>
>;o)
>
>(actually, I'm not sure, but I think that I may not be quite crazy enough
to
>want to deal with this much crap)
>
Re: PCI latency......a whole 'nuther can of worms [message #64148 is a reply to message #64147] Fri, 03 February 2006 16:11 Go to previous messageGo to next message
Deej [1] is currently offline  Deej [1]   UNITED STATES
Messages: 2149
Registered: January 2006
Senior Member
I need all of my ADAT optical outputs to be sending to Paris, not back and
forth between two computers running Cubase. All RME ADAT optical outputs
would need to be feeding Paris ADAT inputs, thus, when mixing in cubase SX
only the ADAT outputs would still be monitored through Paris but the two
Cubase computers would need to be timeline synced to each other and
controlled by the Steinberg Houston controller. Then at final mixdwon, bioth
Cubase computers would need to be slaved to Paris. No ADAT inputs between
the Cubase computers at all.

"gene lennon" <glennon@NOSPmyrealbox.com> wrote in message
news:43e3f190$1@linux...
>
> Not sure if you are joking or going crazy!
>
> Install UAD-1 cards on second computer.
> Use any app like Cubase to host the plugins.
> Send audio back and forth with ADAT optical.
> Link Soundcards with ADAT Clock.
> Done.
> No MIDI, No ADAT Sync, No systemlink, etc.
>
>
> "DJ" <animix_spam-this-ahole_@animas.net> wrote:
> >Hmmmm.....I see what you mean. Seems I've got something here that is a
bit
> >better (and beyond) systemlink anyway. Theoretically, I could split off
> one
> >of my HDSP cards and a couple of the UAD-1 cards, install them on my
second
> >computer, install Cubase SE (or any other PC compatible audio app which
> has
> >PDC) on the second computer, use my network to transfer some tracks (like
> >the drum submix and bass instruments) to one computer and the rest of the
> >audio to the other computer, run ADAT sync cables from ADAT cards in my
> MECs
> >to the audio cards in the two different comps, then apply the UAD-1 FX to
> >the tracks on both computers which are controlled by ADAT sync from the
> >Paris transport. this would be superior to systemlink, most likely. the
> >downside to this is that during a lot of my mix process, I am just
playing
> >back using the Cubase SX transport, streaming the audio via lightpipe
> >feeding Paris with the monitor bus in Paris feeding my DAC-1 . reference
> >system. I only use the Paris transport to slave the Cubase DAW during the
> >last phase of the mix when I'm automating tracks and panning in Paris and
> >then subsequently boundcing down using the Paris mix bus. In order to
have
> >both computers running in sync *without* being controlled by Paris ADAT
> >sync, (which is most of the time I'm mixing) I would need to use a
> >Systemlink compatible Steiny product aand have a spdif connection between
> >the two Steiny machines. I guess, after I finish tracking in Paris,
sending
> >and the tracks from Paris via LAN to WL5 on the Cubase DAW for batch
> >conversion to .wav, I could then further transfer them from the primary
> >Cubase DAW to the secondary Cubase DAW via LAN, then get a couple of my
> >UAD-1 cards authorized for the second DAW.
> >
> >This shouldn't take over a couple of weeks to set up and stabilize and
would
> >involve mixing on three x DAWs plus another comp running as a standalone
> FX
> >processor instead of just two DAWs plus another one running as a
standalone
> >FX processor.
> >
> >Hell man .......piece of cake.
> >
> >;o)
> >
> >(actually, I'm not sure, but I think that I may not be quite crazy enough
> to
> >want to deal with this much crap)
> >
>
Re: PCI latency......a whole 'nuther can of worms [message #64149 is a reply to message #64148] Fri, 03 February 2006 16:18 Go to previous messageGo to next message
Deej [1] is currently offline  Deej [1]   UNITED STATES
Messages: 2149
Registered: January 2006
Senior Member
........and....since this crackling, which is the whole reason behind
speculating on this insanity, is likely being caused by all 4 UAD-1 cards
and all 3 x RMWE cards being shuttled through one host card on a Magma, I'm
going to pull at least one, and maybe two of the UAD-1 cards out of the
Magma and try to use them in normal PCI slots on the mobo. there are 3 x
slots on this board that don't automatically share with the AGP. My old
Cubase DAW never had this problem. I was running 3 x UAD-1 cards in the mobo
PCI slots and the three RME cards plus one UAD-1 card in the Magma.

I know this makes more sense than any of the other stuff, but it's wayyyy
too simple.

;o)


"DJ" <animix_spam-this-ahole_@animas.net> wrote in message
news:43e3f3b6@linux...
> I need all of my ADAT optical outputs to be sending to Paris, not back and
> forth between two computers running Cubase. All RME ADAT optical outputs
> would need to be feeding Paris ADAT inputs, thus, when mixing in cubase SX
> only the ADAT outputs would still be monitored through Paris but the two
> Cubase computers would need to be timeline synced to each other and
> controlled by the Steinberg Houston controller. Then at final mixdwon,
bioth
> Cubase computers would need to be slaved to Paris. No ADAT inputs between
> the Cubase computers at all.
>
> "gene lennon" <glennon@NOSPmyrealbox.com> wrote in message
> news:43e3f190$1@linux...
> >
> > Not sure if you are joking or going crazy!
> >
> > Install UAD-1 cards on second computer.
> > Use any app like Cubase to host the plugins.
> > Send audio back and forth with ADAT optical.
> > Link Soundcards with ADAT Clock.
> > Done.
> > No MIDI, No ADAT Sync, No systemlink, etc.
> >
> >
> > "DJ" <animix_spam-this-ahole_@animas.net> wrote:
> > >Hmmmm.....I see what you mean. Seems I've got something here that is a
> bit
> > >better (and beyond) systemlink anyway. Theoretically, I could split off
> > one
> > >of my HDSP cards and a couple of the UAD-1 cards, install them on my
> second
> > >computer, install Cubase SE (or any other PC compatible audio app which
> > has
> > >PDC) on the second computer, use my network to transfer some tracks
(like
> > >the drum submix and bass instruments) to one computer and the rest of
the
> > >audio to the other computer, run ADAT sync cables from ADAT cards in my
> > MECs
> > >to the audio cards in the two different comps, then apply the UAD-1 FX
to
> > >the tracks on both computers which are controlled by ADAT sync from the
> > >Paris transport. this would be superior to systemlink, most likely. the
> > >downside to this is that during a lot of my mix process, I am just
> playing
> > >back using the Cubase SX transport, streaming the audio via lightpipe
> > >feeding Paris with the monitor bus in Paris feeding my DAC-1 .
reference
> > >system. I only use the Paris transport to slave the Cubase DAW during
the
> > >last phase of the mix when I'm automating tracks and panning in Paris
and
> > >then subsequently boundcing down using the Paris mix bus. In order to
> have
> > >both computers running in sync *without* being controlled by Paris ADAT
> > >sync, (which is most of the time I'm mixing) I would need to use a
> > >Systemlink compatible Steiny product aand have a spdif connection
between
> > >the two Steiny machines. I guess, after I finish tracking in Paris,
> sending
> > >and the tracks from Paris via LAN to WL5 on the Cubase DAW for batch
> > >conversion to .wav, I could then further transfer them from the primary
> > >Cubase DAW to the secondary Cubase DAW via LAN, then get a couple of my
> > >UAD-1 cards authorized for the second DAW.
> > >
> > >This shouldn't take over a couple of weeks to set up and stabilize and
> would
> > >involve mixing on three x DAWs plus another comp running as a
standalone
> > FX
> > >processor instead of just two DAWs plus another one running as a
> standalone
> > >FX processor.
> > >
> > >Hell man .......piece of cake.
> > >
> > >;o)
> > >
> > >(actually, I'm not sure, but I think that I may not be quite crazy
enough
> > to
> > >want to deal with this much crap)
> > >
> >
>
>
Re: PCI latency......a whole 'nuther can of worms [message #64151 is a reply to message #64148] Fri, 03 February 2006 19:12 Go to previous messageGo to next message
gene lennon is currently offline  gene lennon
Messages: 565
Registered: July 2006
Senior Member
Sounds like your main computer (henceforth referred to as “The Mother Ship”);
should have a MADI card, feeding the RME MADI Bridge, feeding multiple ADAT
breakout boxes.

"DJ" <animix_spam-this-ahole_@animas.net> wrote:
>I need all of my ADAT optical outputs to be sending to Paris, not back and
>forth between two computers running Cubase. All RME ADAT optical outputs
>would need to be feeding Paris ADAT inputs, thus, when mixing in cubase
SX
>only the ADAT outputs would still be monitored through Paris but the two
>Cubase computers would need to be timeline synced to each other and
>controlled by the Steinberg Houston controller. Then at final mixdwon, bioth
>Cubase computers would need to be slaved to Paris. No ADAT inputs between
>the Cubase computers at all.
Throw away your can opener! [message #64153 is a reply to message #64151] Fri, 03 February 2006 19:45 Go to previous messageGo to next message
Bill Lorentzen is currently offline  Bill Lorentzen   UNITED STATES
Messages: 140
Registered: June 2005
Senior Member
When I read about what you are doing I am so happy about my simple setup
with 2 computers, a digital mixer and some outboard pres. The mixer provides
all my routing, headphone, talkback and monitoring and I monitor VSTis on
the second machine, while tracking them to the primary machine, to avoid
latency problems. My standard is what I've learned over the years as a
studio owner and engineer: it has to work properly all the time or it is not
professional.

Give yourself a break, man.


"gene lennon" <glennon@NOSPmyrealbox.com> wrote in message
news:43e40d87$1@linux...
>
> Sounds like your main computer (henceforth referred to as "The Mother
> Ship");
> should have a MADI card, feeding the RME MADI Bridge, feeding multiple
> ADAT
> breakout boxes.
>
> "DJ" <animix_spam-this-ahole_@animas.net> wrote:
>>I need all of my ADAT optical outputs to be sending to Paris, not back and
>>forth between two computers running Cubase. All RME ADAT optical outputs
>>would need to be feeding Paris ADAT inputs, thus, when mixing in cubase
> SX
>>only the ADAT outputs would still be monitored through Paris but the two
>>Cubase computers would need to be timeline synced to each other and
>>controlled by the Steinberg Houston controller. Then at final mixdwon,
>>bioth
>>Cubase computers would need to be slaved to Paris. No ADAT inputs between
>>the Cubase computers at all.
>
Re: Throw away your can opener! [message #64154 is a reply to message #64153] Fri, 03 February 2006 20:50 Go to previous messageGo to next message
Deej [1] is currently offline  Deej [1]   UNITED STATES
Messages: 2149
Registered: January 2006
Senior Member
My standard is what I've learned over the years as a
> studio owner and engineer: it has to work properly all the time or it is
not
> professional.
>
> Give yourself a break, man.
>
Hi Bill,

Well.....actually like I said, it's working fine. It's just not doing some
things that I expected. I'm able to access 15 UAD-1 plugins at 40% of the
available resources Any more than that and there is a problem. It may be as
simple as moving a UAD-1 card or *removing* a UAD-1 card. Other than that,
it's rock solid and I have a methodology that is working for me. Also, 15
UAD-1 plugins is a lot. I'm not really complaining about the number, just
the fact that theoretically, I should be able to use 95% of my UAD
resources. In practice, I seldom use 15 UAD plugins in a mix, though those
Pultecs sure come in handy. I probably use the Pultec more than anything
else. Anyway, my earlier rant was speculative, just because I think it's fun
to push this as far as possble, but actually our systems aren't that
different. My digital mixer is Paris. The cue system is a Furman HDS 16
system with remote HRM 16 mixers. This is a very cool and flexible setup. I
track to Paris.I transfer to SX mix back to Paris. It's routed digitally in
a number of ways. I'm used to doing it so it doesn't present any particular
diffuiculties to me. You have a digital mixer and two computers. I have I
have three computers and sync'ed to a house clock one of which functions as
an outboard digital mixer.. No problems there. I've been experimenting with
clock cable runs and have discovered a few limitations there as well, but
it's all good really......just never *perfected*.

;o)
..


"Bill Lorentzen" <bill@lorentzen.ws> wrote in message
news:43e4248c$1@linux...
> When I read about what you are doing I am so happy about my simple setup
> with 2 computers, a digital mixer and some outboard pres. The mixer
provides
> all my routing, headphone, talkback and monitoring and I monitor VSTis on
> the second machine, while tracking them to the primary machine, to avoid
> latency problems. My standard is what I've learned over the years as a
> studio owner and engineer: it has to work properly all the time or it is
not
> professional.
>
> Give yourself a break, man.
>
>
> "gene lennon" <glennon@NOSPmyrealbox.com> wrote in message
> news:43e40d87$1@linux...
> >
> > Sounds like your main computer (henceforth referred to as "The Mother
> > Ship");
> > should have a MADI card, feeding the RME MADI Bridge, feeding multiple
> > ADAT
> > breakout boxes.
> >
> > "DJ" <animix_spam-this-ahole_@animas.net> wrote:
> >>I need all of my ADAT optical outputs to be sending to Paris, not back
and
> >>forth between two computers running Cubase. All RME ADAT optical outputs
> >>would need to be feeding Paris ADAT inputs, thus, when mixing in cubase
> > SX
> >>only the ADAT outputs would still be monitored through Paris but the two
> >>Cubase computers would need to be timeline synced to each other and
> >>controlled by the Steinberg Houston controller. Then at final mixdwon,
> >>bioth
> >>Cubase computers would need to be slaved to Paris. No ADAT inputs
between
> >>the Cubase computers at all.
> >
>
>
Re: Throw away your can opener! [message #64162 is a reply to message #64154] Sat, 04 February 2006 07:30 Go to previous messageGo to next message
Bill Lorentzen is currently offline  Bill Lorentzen   UNITED STATES
Messages: 140
Registered: June 2005
Senior Member
DJ,

I did not mean to sound condescending or like I was putting your system
down. I just had the impression you were having trouble with it. Anyway,
it's your game and you should play any way you want. I just like to share my
successful actions with others in case they can use the tips. Have fun!

BTW I am really interested in your possible mic shoot-out of the Gemini and
the 47. I am thinking about getting a Gemini (when I have some time to
really check it out).

Bill

"DJ" <animix_spam-this-ahole_@animas.net> wrote in message
news:43e4354c@linux...
> My standard is what I've learned over the years as a
>> studio owner and engineer: it has to work properly all the time or it is
> not
>> professional.
>>
>> Give yourself a break, man.
>>
> Hi Bill,
>
> Well.....actually like I said, it's working fine. It's just not doing some
> things that I expected. I'm able to access 15 UAD-1 plugins at 40% of the
> available resources Any more than that and there is a problem. It may be
> as
> simple as moving a UAD-1 card or *removing* a UAD-1 card. Other than that,
> it's rock solid and I have a methodology that is working for me. Also, 15
> UAD-1 plugins is a lot. I'm not really complaining about the number, just
> the fact that theoretically, I should be able to use 95% of my UAD
> resources. In practice, I seldom use 15 UAD plugins in a mix, though those
> Pultecs sure come in handy. I probably use the Pultec more than anything
> else. Anyway, my earlier rant was speculative, just because I think it's
> fun
> to push this as far as possble, but actually our systems aren't that
> different. My digital mixer is Paris. The cue system is a Furman HDS 16
> system with remote HRM 16 mixers. This is a very cool and flexible setup.
> I
> track to Paris.I transfer to SX mix back to Paris. It's routed digitally
> in
> a number of ways. I'm used to doing it so it doesn't present any
> particular
> diffuiculties to me. You have a digital mixer and two computers. I have I
> have three computers and sync'ed to a house clock one of which functions
> as
> an outboard digital mixer.. No problems there. I've been experimenting
> with
> clock cable runs and have discovered a few limitations there as well, but
> it's all good really......just never *perfected*.
>
> ;o)
> .
>
>
> "Bill Lorentzen" <bill@lorentzen.ws> wrote in message
> news:43e4248c$1@linux...
>> When I read about what you are doing I am so happy about my simple setup
>> with 2 computers, a digital mixer and some outboard pres. The mixer
> provides
>> all my routing, headphone, talkback and monitoring and I monitor VSTis on
>> the second machine, while tracking them to the primary machine, to avoid
>> latency problems. My standard is what I've learned over the years as a
>> studio owner and engineer: it has to work properly all the time or it is
> not
>> professional.
>>
>> Give yourself a break, man.
>>
>>
>> "gene lennon" <glennon@NOSPmyrealbox.com> wrote in message
>> news:43e40d87$1@linux...
>> >
>> > Sounds like your main computer (henceforth referred to as "The Mother
>> > Ship");
>> > should have a MADI card, feeding the RME MADI Bridge, feeding multiple
>> > ADAT
>> > breakout boxes.
>> >
>> > "DJ" <animix_spam-this-ahole_@animas.net> wrote:
>> >>I need all of my ADAT optical outputs to be sending to Paris, not back
> and
>> >>forth between two computers running Cubase. All RME ADAT optical
>> >>outputs
>> >>would need to be feeding Paris ADAT inputs, thus, when mixing in cubase
>> > SX
>> >>only the ADAT outputs would still be monitored through Paris but the
>> >>two
>> >>Cubase computers would need to be timeline synced to each other and
>> >>controlled by the Steinberg Houston controller. Then at final mixdwon,
>> >>bioth
>> >>Cubase computers would need to be slaved to Paris. No ADAT inputs
> between
>> >>the Cubase computers at all.
>> >
>>
>>
>
>
Re: PCI latency......a whole 'nuther can of worms [message #64178 is a reply to message #64151] Sat, 04 February 2006 23:21 Go to previous messageGo to next message
LaMont is currently offline  LaMont
Messages: 828
Registered: October 2005
Senior Member
yes sir. Madi will do simplify things alot.


"gene lennon" <glennon@NOSPmyrealbox.com> wrote:
>
>Sounds like your main computer (henceforth referred to as “The Mother Ship”);
>should have a MADI card, feeding the RME MADI Bridge, feeding multiple ADAT
>breakout boxes.
>
>"DJ" <animix_spam-this-ahole_@animas.net> wrote:
>>I need all of my ADAT optical outputs to be sending to Paris, not back
and
>>forth between two computers running Cubase. All RME ADAT optical outputs
>>would need to be feeding Paris ADAT inputs, thus, when mixing in cubase
>SX
>>only the ADAT outputs would still be monitored through Paris but the two
>>Cubase computers would need to be timeline synced to each other and
>>controlled by the Steinberg Houston controller. Then at final mixdwon,
bioth
>>Cubase computers would need to be slaved to Paris. No ADAT inputs between
>>the Cubase computers at all.
>
Re: Throw away your can opener! [message #64211 is a reply to message #64162] Sun, 05 February 2006 18:38 Go to previous message
Deej [1] is currently offline  Deej [1]   UNITED STATES
Messages: 2149
Registered: January 2006
Senior Member
Hi Bill,

Your system sounds very nice indeed and I've often thought of moving to a
dedicated digital mixer myself. As long as this old dog continues to hunt,
I'll leep feeding it.

;o)



"Bill Lorentzen" <bill@lorentzen.ws> wrote in message
news:43e4c9c9$1@linux...
> DJ,
>
> I did not mean to sound condescending or like I was putting your system
> down. I just had the impression you were having trouble with it. Anyway,
> it's your game and you should play any way you want. I just like to share
my
> successful actions with others in case they can use the tips. Have fun!
>
> BTW I am really interested in your possible mic shoot-out of the Gemini
and
> the 47. I am thinking about getting a Gemini (when I have some time to
> really check it out).
>
> Bill
>
> "DJ" <animix_spam-this-ahole_@animas.net> wrote in message
> news:43e4354c@linux...
> > My standard is what I've learned over the years as a
> >> studio owner and engineer: it has to work properly all the time or it
is
> > not
> >> professional.
> >>
> >> Give yourself a break, man.
> >>
> > Hi Bill,
> >
> > Well.....actually like I said, it's working fine. It's just not doing
some
> > things that I expected. I'm able to access 15 UAD-1 plugins at 40% of
the
> > available resources Any more than that and there is a problem. It may be
> > as
> > simple as moving a UAD-1 card or *removing* a UAD-1 card. Other than
that,
> > it's rock solid and I have a methodology that is working for me. Also,
15
> > UAD-1 plugins is a lot. I'm not really complaining about the number,
just
> > the fact that theoretically, I should be able to use 95% of my UAD
> > resources. In practice, I seldom use 15 UAD plugins in a mix, though
those
> > Pultecs sure come in handy. I probably use the Pultec more than anything
> > else. Anyway, my earlier rant was speculative, just because I think it's
> > fun
> > to push this as far as possble, but actually our systems aren't that
> > different. My digital mixer is Paris. The cue system is a Furman HDS 16
> > system with remote HRM 16 mixers. This is a very cool and flexible
setup.
> > I
> > track to Paris.I transfer to SX mix back to Paris. It's routed digitally
> > in
> > a number of ways. I'm used to doing it so it doesn't present any
> > particular
> > diffuiculties to me. You have a digital mixer and two computers. I have
I
> > have three computers and sync'ed to a house clock one of which functions
> > as
> > an outboard digital mixer.. No problems there. I've been experimenting
> > with
> > clock cable runs and have discovered a few limitations there as well,
but
> > it's all good really......just never *perfected*.
> >
> > ;o)
> > .
> >
> >
> > "Bill Lorentzen" <bill@lorentzen.ws> wrote in message
> > news:43e4248c$1@linux...
> >> When I read about what you are doing I am so happy about my simple
setup
> >> with 2 computers, a digital mixer and some outboard pres. The mixer
> > provides
> >> all my routing, headphone, talkback and monitoring and I monitor VSTis
on
> >> the second machine, while tracking them to the primary machine, to
avoid
> >> latency problems. My standard is what I've learned over the years as a
> >> studio owner and engineer: it has to work properly all the time or it
is
> > not
> >> professional.
> >>
> >> Give yourself a break, man.
> >>
> >>
> >> "gene lennon" <glennon@NOSPmyrealbox.com> wrote in message
> >> news:43e40d87$1@linux...
> >> >
> >> > Sounds like your main computer (henceforth referred to as "The Mother
> >> > Ship");
> >> > should have a MADI card, feeding the RME MADI Bridge, feeding
multiple
> >> > ADAT
> >> > breakout boxes.
> >> >
> >> > "DJ" <animix_spam-this-ahole_@animas.net> wrote:
> >> >>I need all of my ADAT optical outputs to be sending to Paris, not
back
> > and
> >> >>forth between two computers running Cubase. All RME ADAT optical
> >> >>outputs
> >> >>would need to be feeding Paris ADAT inputs, thus, when mixing in
cubase
> >> > SX
> >> >>only the ADAT outputs would still be monitored through Paris but the
> >> >>two
> >> >>Cubase computers would need to be timeline synced to each other and
> >> >>controlled by the Steinberg Houston controller. Then at final
mixdwon,
> >> >>bioth
> >> >>Cubase computers would need to be slaved to Paris. No ADAT inputs
> > between
> >> >>the Cubase computers at all.
> >> >
> >>
> >>
> >
> >
>
>
Previous Topic: Tracking/Overdubs and Latency
Next Topic: And what happenned to www.analogx.com...?
Goto Forum:
  


Current Time: Fri May 17 06:20:04 PDT 2024

Total time taken to generate the page: 0.03607 seconds