Mixing in Scope - Device latencies/phase problems

[Yogimeister]

I tried /usepmtimer - but didnt see any change in performance ...

Should I enable ACPI2 though (for it to make a difference)?

[djmicron]

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.

[Bud Weiser]

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.

Yes, I know, but it´s only true as long as you run it as a completely separated system.
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.

Scope physical midi output is hardware midi, calculated on the dsp's. Running an RTOS.

I know that too.

The sequencer midi is different as it communicates with windows.

There we have it ...

Bud

[Yogimeister]

it should improve the acpi functionality, but i can't say if it will improve your system timing.

I have googled that its the equivalent to HPET in Intel world ... But Im not 100% sure ...
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]

midi is midi and windows is windows.
if you need tighter midi, use a hardware sequencer or an Atari.

thank you !

Bud

[Bud Weiser]

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.

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?

So of course, some systems or combination of drivers means default use or even disabling HPET may be better.

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 ?

Bud

[astroman]

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

[fra77x]

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...

[astroman]

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

[fra77x]

"hardware transmitters"
"the timebase of the system"
"that drives"
"by context"

[hubird]

[garyb]

bruh.jpg (42.28 KiB) Viewed 3230 times

if you put lipstick on it, a pig is still a pig.
if you marry it, you will still be hugging and kissing a pig.

cat_jumps_off_balcony_ledge.gif (3.37 MiB) Viewed 3230 times

[fra77x]

!

[jksuperstar]

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?

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:
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)

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 ?

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).

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

[garyb]

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.

[fra77x]

@ 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.

[astroman]

you're a little late, we've had that one in the first answer already...
quoting myself:

you 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)

but for some reason yogimeister really wants to dig it down to the microsecond
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

[fra77x]

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!

[astroman]

lmao

cheers, Tom

[djmicron]

it should improve the acpi functionality, but i can't say if it will improve your system timing.

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??)

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.

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 ?

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.