Mixing in Scope - Device latencies/phase problems
-
- Posts: 323
- Joined: Sat Jan 12, 2008 10:12 am
Re: Mixing in Scope - Device latencies/phase problems
I tried /usepmtimer - but didnt see any change in performance ...
Should I enable ACPI2 though (for it to make a difference)?
Should I enable ACPI2 though (for it to make a difference)?
Re: Mixing in Scope - Device latencies/phase problems
it should improve the acpi functionality, but i can't say if it will improve your system timing.
I have not read in detail the entire conversation, but if you haven't already done it, try to check your timing settings by running this tool :
http://technet.microsoft.com/en-us/sysi ... 97568.aspx
open up a cmd window and drag that exe file inside, then hit enter on your keyboard and you'll see the windows timing accuracy.
Make this test while cubase is running to see how is the timing during your audio sessions.
I have not read in detail the entire conversation, but if you haven't already done it, try to check your timing settings by running this tool :
http://technet.microsoft.com/en-us/sysi ... 97568.aspx
open up a cmd window and drag that exe file inside, then hit enter on your keyboard and you'll see the windows timing accuracy.
Make this test while cubase is running to see how is the timing during your audio sessions.
- Bud Weiser
- Posts: 2687
- Joined: Tue Sep 14, 2010 5:29 am
- Location: nowhere land
Re: Mixing in Scope - Device latencies/phase problems
Yes, I know, but it´s only true as long as you run it as a completely separated system.fra77x wrote:
That is not the case. Scope uses it's internal oscillators. It is a completely separated system from the computer you are running the software on. 95% are algo's calculated on the dsp's.
Yogimeister uses it different,- he transmits MIDI info from Cubase into SCOPE, so there´s Windows in the ballpark for a timing critical task and I don´t believe Windows uses SCOPE´s internal oscillators´ clock as a reference.
I know that too.fra77x wrote: Scope physical midi output is hardware midi, calculated on the dsp's. Running an RTOS.
There we have it ...fra77x wrote:
The sequencer midi is different as it communicates with windows.
Bud
S|C Scope/XITE-1 & S|C A16U, Scope PCI & CW A16U
-
- Posts: 323
- Joined: Sat Jan 12, 2008 10:12 am
Re: Mixing in Scope - Device latencies/phase problems
I have googled that its the equivalent to HPET in Intel world ... But Im not 100% sure ...djmicron wrote:it should improve the acpi functionality, but i can't say if it will improve your system timing.
Ill research ot a bit more before enabling (any advice would be appreciated if anyone knows this ...)
Regarding the clockres:
With scooe and cubase loaded - I get:
Max time interval: 15.625 ms
Min time int : 1ms
Current time int: 0.977 ms
Any Insights ? (Are these good results??)
- Bud Weiser
- Posts: 2687
- Joined: Tue Sep 14, 2010 5:29 am
- Location: nowhere land
Re: Mixing in Scope - Device latencies/phase problems
thank you !garyb wrote:midi is midi and windows is windows.
if you need tighter midi, use a hardware sequencer or an Atari.
Bud
S|C Scope/XITE-1 & S|C A16U, Scope PCI & CW A16U
- Bud Weiser
- Posts: 2687
- Joined: Tue Sep 14, 2010 5:29 am
- Location: nowhere land
Re: Mixing in Scope - Device latencies/phase problems
O.k. that´s informative and I´ve read what it is.jksuperstar wrote:
If you use Win XP sp2 or earlier, the TGT/QPC timer is an especially odd issue as Bud noted. WinXP SP3, Vista, Win7, and Win8 all support the newer HPET timer that is built in to all southbridge chips since 2005.
I assume the HPET timer can only be used by post 2005 devices,- right?
It improves USB2 (and USB3) because that is what Windows uses for MIDI data transfers?
To me that means, when you own older 8x8 USB (1.1) MIDI interfaces and install their drivers, these interfaces won´t profit from HPET.jksuperstar wrote: So of course, some systems or combination of drivers means default use or even disabling HPET may be better.
Is that correct ?
What about XITE-1 (or SCOPE PCI cards) when using it at the only audio/MIDI interface, using it´s MIDI-Out for outgoing MIDI coming via Seq-MIDI Source into SCOPE ?
Bud
S|C Scope/XITE-1 & S|C A16U, Scope PCI & CW A16U
Re: Mixing in Scope - Device latencies/phase problems
that would be the most logical step to begin with... tell the sequencer to use Scope's Midi clock as it's time base
however: just because it's hardware doesn't make it more reliable by nature
hardware can have zero to 400 samples 'jitter'
(measured the way yogimeister mentioned - also described and collected on the previously linked site)
http://www.innerclocksystems.com/new%20 ... itmus.html
few systems are below 5 samples, many seem to fall into the 20-50 samples range
dunno how Cubase will treat external clock, tho...
will it adjust it's own timers to that or will it quantize according to it's PC timebase ?
(the latter for keeping just the 'beat' in sync)
cheers, Tom
however: just because it's hardware doesn't make it more reliable by nature
hardware can have zero to 400 samples 'jitter'
(measured the way yogimeister mentioned - also described and collected on the previously linked site)
http://www.innerclocksystems.com/new%20 ... itmus.html
few systems are below 5 samples, many seem to fall into the 20-50 samples range
dunno how Cubase will treat external clock, tho...
will it adjust it's own timers to that or will it quantize according to it's PC timebase ?
(the latter for keeping just the 'beat' in sync)
cheers, Tom
Re: Mixing in Scope - Device latencies/phase problems
do you know what midi clock is?
What it has to do with midi jitter?
http://en.wikipedia.org/wiki/MIDI_beat_clock
http://en.wikipedia.org/wiki/MIDI_timecode
And because i' m bored: Sending midi clock actually degrades your midi accuracy...
What it has to do with midi jitter?
http://en.wikipedia.org/wiki/MIDI_beat_clock
http://en.wikipedia.org/wiki/MIDI_timecode
And because i' m bored: Sending midi clock actually degrades your midi accuracy...
Re: Mixing in Scope - Device latencies/phase problems
sorry, but I thought what this 'clock' meant was clear by context ...
(the timebase of the system that drives hardware transmitters in external devices)
cheers, Tom
(the timebase of the system that drives hardware transmitters in external devices)
cheers, Tom
Re: Mixing in Scope - Device latencies/phase problems
"hardware transmitters"
"the timebase of the system"
"that drives"
"by context"
"the timebase of the system"
"that drives"
"by context"
Re: Mixing in Scope - Device latencies/phase problems
if you marry it, you will still be hugging and kissing a pig.
Re: Mixing in Scope - Device latencies/phase problems
!
Last edited by fra77x on Tue Jan 06, 2015 12:30 pm, edited 1 time in total.
-
- Posts: 1638
- Joined: Mon Nov 15, 2010 12:57 pm
Re: Mixing in Scope - Device latencies/phase problems
I don't know exactly when or where the HPET timer showed up, but it is required for WHQL now (windows certification). It also seems the timer was a bit ambiguous in definition early on, but seems to be more standard now. Forcing the system to use 1 timer does two things:Bud Weiser wrote: O.k. that´s informative and I´ve read what it is.
I assume the HPET timer can only be used by post 2005 devices,- right?
It improves USB2 (and USB3) because that is what Windows uses for MIDI data transfers?
1 - You can't have a driver use 1 timer, while the DAW uses another. Eventually they drift. So the system has to play games to align them the best it can...hence the added switch to force use of a system timer, etc.
2 - The HPET has a higher resolution...this is the analogous to your DAW using 960PPQN vs. 480PPQN. It means any time stamps added to any data..MIDI or other, can have a better understanding of when it arrived (ie - in theory...less quantization at milliseconds levels, so in theory, less jitter)
In my experience, devices that have both audio and MIDI will be addressed together by the system...so lower ULLI settings means the system services the XITE more times per second, which means less MIDI latency. I *feel* that is true with my XITE. I don't have a PCI system to compare to, nor any real empirical data to show. I use BCModular clocks in SCOPE to drive Ableton Live via a dedicated SCOPE Sequencer input (no other data on that port), and the drift is in the range of hundredths of BPM. I'm pretty happy with those results, even if I have to set the Tempo outside of my DAW. I do have the option of automating those tempo changes via MIDI though, which means most DAWs could configure that clock when a project is loaded. (Not so with Ableton Live).Bud wrote: To me that means, when you own older 8x8 USB (1.1) MIDI interfaces and install their drivers, these interfaces won´t profit from HPET.
Is that correct ?
What about XITE-1 (or SCOPE PCI cards) when using it at the only audio/MIDI interface, using it´s MIDI-Out for outgoing MIDI coming via Seq-MIDI Source into SCOPE ?
I no longer have any older USB devices (everything I have is "USB MIDI compliant" now, and I use an iConnectMIDI4+ so nothing is attached to the PC USB anymore), so I'm not sure I can help there. It's one of those "try it in your system and see" things. No good algorithm I know of to predict performance for all systems
Re: Mixing in Scope - Device latencies/phase problems
fra77x, i mean, SMILE!
what do you mean?
if we have to completely tear apart the computer to get it to do what we want to do, then maybe it would be better to use tools that do what we want already. a computer is a general use device. it works GREAT for most things, but some things it doesn't do well and because of the design of a modern computer, where internet and streaming video/multimedia is the main focus, some realtime functions are just ok(like midi timing). a hardware sequencer won't be nearly as random. a hammer can be used to fix almost anything, but if it's something that needs any delicacy, the proper tool might be more successful.
what do you mean?
if we have to completely tear apart the computer to get it to do what we want to do, then maybe it would be better to use tools that do what we want already. a computer is a general use device. it works GREAT for most things, but some things it doesn't do well and because of the design of a modern computer, where internet and streaming video/multimedia is the main focus, some realtime functions are just ok(like midi timing). a hardware sequencer won't be nearly as random. a hammer can be used to fix almost anything, but if it's something that needs any delicacy, the proper tool might be more successful.
Re: Mixing in Scope - Device latencies/phase problems
@ Gary
Ok, sorry
@ discussion
There is one very easy way to test your midi timing. No stupid tests or whatever. Put 16 32th notes in a loop bar in your sequencer grid. Drive a kick /sampler whatever that retriggers the oscillator on each note on and has clear attack transient. Raise the tempo to 200+
If you hear a constant sound that is straight without any irregular beating or artifacts your timing is ok. If not search until you find such a sequencer or method to obtain such results.
You can thank me another day.
Ok, sorry
@ discussion
There is one very easy way to test your midi timing. No stupid tests or whatever. Put 16 32th notes in a loop bar in your sequencer grid. Drive a kick /sampler whatever that retriggers the oscillator on each note on and has clear attack transient. Raise the tempo to 200+
If you hear a constant sound that is straight without any irregular beating or artifacts your timing is ok. If not search until you find such a sequencer or method to obtain such results.
You can thank me another day.
Re: Mixing in Scope - Device latencies/phase problems
you're a little late, we've had that one in the first answer already...
quoting myself:
possibly not the most 'musical' decision, but if he wants to... ok
and in that case you can simply forget about your 'great' test scenario
the proper way is to let the midi system trigger a transient audio event in constant (time) intervals
the event is recorded and displacement of peaks is measured by counting samples in between
usually the events drift - for example the metronome of my Korg Pandora practicing amp is +- 1ms off
(I noticed it by chance when using the device for latency testing: sometimes 10, sometimes 12 ms in the same setup)
cheers, Tom
quoting myself:
but for some reason yogimeister really wants to dig it down to the microsecondyou really should not take it too serious - it can drive you nuts to align everything down to the sample level
it won't sound better because it is aligned (in fact many sounds need some 'displacement' to please the ear)
possibly not the most 'musical' decision, but if he wants to... ok
and in that case you can simply forget about your 'great' test scenario
the proper way is to let the midi system trigger a transient audio event in constant (time) intervals
the event is recorded and displacement of peaks is measured by counting samples in between
usually the events drift - for example the metronome of my Korg Pandora practicing amp is +- 1ms off
(I noticed it by chance when using the device for latency testing: sometimes 10, sometimes 12 ms in the same setup)
cheers, Tom
Re: Mixing in Scope - Device latencies/phase problems
You don't know what you are talking about.
yogimeister sense as i can understand is in the ms range.
"in fact many sounds need some 'displacement' to please the ear"
One of the funniest things i have ever heard. Displacement should be accurate, not whatever...
"the proper way is to let the midi system trigger a transient audio event in constant (time) intervals
the event is recorded and displacement of peaks is measured by countig samples "
Before discussing the proper way feel free to get to know what you are talking about.
We are talking music here and sound.
"usually the events drift"
In your system always.. In mine never. Sample accurate, do you know what it means?
"I noticed it by chance"
Not by chance my friend. Your events drift by necessity...
"it won't sound better because it is aligned"
You are way beyond!
yogimeister sense as i can understand is in the ms range.
"in fact many sounds need some 'displacement' to please the ear"
One of the funniest things i have ever heard. Displacement should be accurate, not whatever...
"the proper way is to let the midi system trigger a transient audio event in constant (time) intervals
the event is recorded and displacement of peaks is measured by countig samples "
Before discussing the proper way feel free to get to know what you are talking about.
We are talking music here and sound.
"usually the events drift"
In your system always.. In mine never. Sample accurate, do you know what it means?
"I noticed it by chance"
Not by chance my friend. Your events drift by necessity...
"it won't sound better because it is aligned"
You are way beyond!
Re: Mixing in Scope - Device latencies/phase problems
lmao
cheers, Tom
cheers, Tom
Re: Mixing in Scope - Device latencies/phase problems
it's the best value you can afford using xp sp2, while on win 7 it's 0.5 ms and it should be better if you update to sp3.Yogimeister wrote:Regarding the clockres:djmicron wrote:it should improve the acpi functionality, but i can't say if it will improve your system timing.
With scooe and cubase loaded - I get:
Max time interval: 15.625 ms
Min time int : 1ms
Current time int: 0.977 ms
Any Insights ? (Are these good results??)
the problem comes when the midi is sent from sequencer to midi destinations, it's good on win 7 with the xite, the randomness is almost inaudible and i have to say that i have made a test running reaper under linux over wine and the midi timing is better.What about XITE-1 (or SCOPE PCI cards) when using it at the only audio/MIDI interface, using it´s MIDI-Out for outgoing MIDI coming via Seq-MIDI Source into SCOPE ?