Engineering logs of scope ?

[nebelfuerst]

Is there a way to make scope report more details about it's internals ?
e.g.: I'd like to check for sync errors on the ADat-inputs.
( Today I have to run very long recordings and check them... would be much easier, if I could grep through a detailed log.)

[astroman]

imho there are 2 types of sync errors:
most obvious the lightpipe based kind (dirt, bad sitting) and the system/interupt kind
The latter would be hard to track by software logs, as the software fails because the error happens on a lower level about which it has no information at all.

I recently did one of those 'cleanup every 4 years' mantainance actions and it was puzzling as usual... so to say.
To get better physical access to the SATA ports I reseated cards, which resulted in one config that didn't even allow to choose 96khz sampling rate as Scope master.
Screen redraw was ultra slow (trail images when dragging items), but in this mess Solaris performed with a very nice tone.
It was clear that IRQ sharing was awefully wrong and in fact moving the cards to different slots solved the issue,
Redraws were cured and samplerste could be set ... but wtf: Solaris sounded like shite... I'm totally clueless about that.
All the other stuff seems to run fine, in particular at least one of the old EarlyFirst reverbs, which failed in the mess before late spring cleaning.

I admit that's about a Win XP SP3 system and not representative for most current installations, but none of these errors would have been revealed by log files. That I was able to handle it is based on pure experience over many years with the system, not deep knowledge about Win internals. It's plainly not rational oh so many times

Best of luck - keep your Adats clean and check IRQ sharing, fingers crossed...

[at0m]

nebelfuerst,

IMO, ADAT sync error's and other hardware IO problems aren't caused by system load - the ADAT ports don't care what load the system is under. Or about IRQ's. The OS wouldn't even know about such errors, since that's all Scope's business on the DSPs. And I don't know of a way to monitor or log that. You could try the obvious 'verbose' 'log' or other command line switches, prepend them with '-' (nix style) or '/' (windows), but I don't know of any apart from '$PATH/sfp.exe -s' which launches the startup project in the tray. Note sfp.exe's linux/unix style '-' for switches here.

/Driver/ errors however are totally unrelated to hw IO. Software IO, like buffer underruns due to insufficient throughput on the PCI bus and/or CPU load or spikes, are the driver client's business - the DAW. Cubase, Ableton, whatever's using the drivers. Ardour for example defaults to inserting markers whenever an xrun occurs. For these buffer underruns, I'd consult with the DAW's documentation.


astroman,

maybe Solaris has some internal delays hardcoded so they work best at 44.1kHz? I remember DeFeX/Neutron7 device (and there's probably others) where user would set the project's samplerate (or was it latency?) on the device in order to make delay times match. Under the hood, the frontpanel's delay time would take that in account and subtract the card's samplerate/latency to set the delay time on the actual delay atom. Reason was that the systemic buffer would be added to the delay atom's actual delay time, the sum of these totalled the displayed or user set delay time. At 96kHz, adjusting Solaris preset made at 44.1 to the new samplerate by hand/ear could solve that "bad sound".
Another reason I could think of is when different parts Solaris (the synth engine, the fx, or worse even different parts of the synth engine - it's such a beast-) are loaded on DSP on different cards. Cycling samplerate to force a DSP-reload could solve this issue.

[astroman]

not to distract from the original topic, just to keep things clean: the 96k issue wasn't related to Solaris, it was an empty project that took longer as usual when switching sample rate, but refused 96k completely.
Slot change got the main card an unshared IRQ and both screen refresh and sample rate problems were fixed.

While Solaris did sound really good in the 'bad setup', it's sound engine now was completely off.
Thin and faint distortion at regular levels, hard to describe ... similiar to S/PDIF with wrong cables, not properly synced and jitter galore (never heard something like that in all my years on any Scope synth).
You're probably right with the cross cards distribution suspect, as I tried multiple versions with similiar results.
(it's not a big deal as Solaris is too 'big' for me anyway atm, as you wrote... a huge beast)

back on topic
Imho Adat sync is (kind of) IRQ dependant - the clock itself is plain hardware of course, but the software cannot react properly if the card gets hickupped by whatever is sharing with it's IRQ. Dunno for sure, but I'd highly suspect it...

[at0m]

the software cannot react properly if the card gets hickupped by whatever is sharing with it's IRQ. Dunno for sure, but I'd highly suspect it...

right, the software, that's drivers - ASIO, wav,..
ADAT, that's hardware. Windows can BSOD and it will still work.

[valis]

What cards do yo have again astro?

[astroman]

humble: Pulsar 2 plus Pulsar 1 in a Gigabyte EP41 board, CPU is a 3Ghz Dualcore clocked to 2.4 for less fan noise.
SAW Studio doesn't need much juice and projects rarely exceed 8 tracks.
The old EarlyFirst PT2036 (demo) reverb seems to be an interesting indicator: there are occasional glitches when the system is idle (similiar to kicking a spring reverb tank) in minute intervals, which came in every 15 seconds in the former installation.
(btw I always had trouble with devices using the very long delay dsp atom, so it may be specific to my hardware)
But the smaller PT2016 reverb is now sounding nice again - it was completely unusable before.

[valis]

Most delays & reverbs are async as well as sync, which means they use the host to buffer the delay lines.

Solaris is most likely a DSP allocation issue, with certain atoms winding up spread too far across DSP as your load hits a maximum on your first DSPs. Which card shows first in your DSP meter? the 6 or the 4?

[astroman]

Of course the 6 DSP card
But Solaris was (is) the only item in the project and it happened with the default init patch at 1 voice poly.
It wasn't any heavy synth use (which I wouldn't do anyway - rarely exceeding 3 voice poly).
Actually it doesn't bother me at all, but I found the observation worth mentioning in this context of system examining.
Funny thing is that Solaris acts reverse to the PT Reverbs, which had their crappy tone on the 'messed' installation (understandable) and seem fixed now, while Solaris was always ok and now sounds like a cheapo VST.
Btw I always checked the items individually, not reverb and synth together - and it's mostly curiosity about what's going on.

Synth isn't my premier domain anyway, but I have to admit the PT reverbs impressed me heavily when feeding old TX-7 sounds via analog input to them.
And I'm not too picky with 2 DSP cards that have had almost 20 years of usage

[valis]

Glad you had done all you could to assure the larger card was first and all else was in order. It's also possible you just prefer a circuit bent Solaris (I jest)

[nebelfuerst]

To get back to my initial topic:
I just bought new toslink-cables, but sync errors are just an example for my question, you could also name the linkcable between scopes or the pci-interface.
As I am a robustness perfectionist, I try to test if there are any clitches in my equipment by stresstesting it.

If there's a crackle every minute, it is easy to spot, but how to check for crackles every hour ?
While access to internal error reports is quite common on linux, even samplitude reports them after recording.
So the question remains, if there is any way to get to the scope internals for easier quality assurance.

[astroman]

oops, sorry for distraction... got farther than intended
As mentioned it's easy to check the hardware:
if you always kept the TosLink transmitters closed when not in use, there's no dirt to be expected inside.
Otherwise blow compressed air into the holes.
At least the Scope main card should have an unshared IRQ (to be on the safe side).
That's the fundamental part - which you probably know anyway, but it can be tricky with some modern boards.

A lot (!) of Scope depends on the basic Windows installation and the Visual C++ runtime distribution, which may collide with other installs on your machine. It shouldn't (according to specs), but shit just happens...
(you may consider an exchangeable boot drive with a lean Win installation dedicated to Scope and recording)

If there's anything wrong regarding sync in such an installation, it will show up almost immediately, but that's very unlikely.
Depending on age of your Adat gear you may check that as well. For example record half an hour of silence with an external converter clocking Scope.
Beware though: an open input channel picks up quite some electric noise from the environment
(proper approach would be to terminate each plug by resistors according to channel input impedance)

Imho that's about what you (and anyone else) is able to check and control.
Problems that show up despite such a proper setup are beyond the scope of us regular humans.

It would need the full developement systems for hardware and software, specs and documentation.
Even that doesn't help sometimes, as recently discussed in context of the Modular 4 tape delay module.
The error showed up on some hardware and not on other while both systems had the exact same installation an noone at Creamware (iirc) had a clue about what was going on.

Imho it's not worth overestimating error possibilities - they simply exist with any electrical installation and all the mobile signalling floating around us.

[garyb]

no, there is nothing that can tell you what is failing, if anything.
crackles can come from almost anywhere. they indicate lost data. if the hardware is good and the computer is properly setup, there should be no issues, period.

is something like a plugin overdriving?
are the ADAT ports clean?
have you disabled power stepping in the bios and os?
heavy vst load?
etc.

it is easy to blame Scope(and it may be a problem in Scope), but it could also be unrelated to Scope, specifically.