KVR Audio

mystran · Post by **mystran** » Tue Jul 30, 2013 9:06 pm

tico-tico wrote:Win7 SP1 x32 + Reaper + sforzando + dust eq (actually anything from Signaldust) = crash on my system
Problem Event Name: APPCRASH
Application Name: reaper.exe
Application Version: 4.4.0.0
Application Timestamp: 517c0642
Fault Module Name: atioglxx.dll
Fault Module Version: 6.14.10.11318
Fault Module Timestamp: 4ebb3dc2
Exception Code: c0000005
Exception Offset: 00cf7440
OS Version: 6.1.7601.2.1.0.768.2
Locale ID: 1049
Edit: I mean Dust Eq v1.0.5.1

Does this only happen when using my plugins together with sforzando? Is it random or consistent?

The "atioglxx.dll" looks like your OpenGL drivers don't like something, and the particular version is from Catalyst 11.12 (so december 2011, probably fine).

tico-tico · Post by **tico-tico** » Tue Jul 30, 2013 9:18 pm

Reaper crashes only if i have sforzando in my project, it is consistent.
Create new track in Reaper, add sforsando to the track, add Dust Eq to the track - Reaper crashes immediately.

mystran · Post by **mystran** » Tue Jul 30, 2013 9:28 pm

tico-tico wrote:Reaper crashes only if i have sforzando in my project, it is consistent.
Create new track in Reaper, add sforsando to the track, add Dust Eq to the track - Reaper crashes immediately.

Thanks, I'll try if I can reproduce it.

mystran · Post by **mystran** » Wed Jul 31, 2013 11:00 am

This http://www.plogue.com/products/sforzando/ ?

I managed to reproduce some OpenGL related issue even on NVidia (specifically when leaving my private OpenGL context after rendering), and I'll continue to investigate whether there's anything I'm doing wrong (and why sforzando triggers such a crash). but basically I kinda doubt it's my fault, because I'm getting a number of problems with sforzando, even before I even load any of my plugins (which arguably seem sensitive to this).

Among the silly things that sforzando does, here's my favourite:

Code: Select all

6C58AC23  xor         eax,eax 
6C58AC25  mov         dword ptr [eax],ecx

That basically says "write to location zero, on purpose" and it does that every single time I load the plugin. It still somehow survives (probably catches the resulting exception), but seriously WTF?

[edit: for those wondering, I very rarely even look at the disassembly where crashes happen, because usually it's totally useless to do so.. but MSVC debugger opens it anyway, and somehow the above just caught my eyes]

mystran · Post by **mystran** » Wed Jul 31, 2013 11:28 am

Urgh.. seems really non-deterministic on my system though.. could be the NVidia drivers doing workarounds (they are pretty tolerant of total non-sense)..

Anyway, one possible work-around would be running my plugins as bridged. I know it's less than ideal, but it should prevent the two from messing with each other..

tico-tico · Post by **tico-tico** » Wed Jul 31, 2013 11:32 am

yep

First-chance exception at 0x5e0aac25 in reaper.exe: 0xC0000005: Access violation writing location 0x00000000.

and it works without crashes with attached debugger

Edit:

Anyway, one possible work-around would be running my plugins as bridged. I know it's less than ideal, but it should prevent the two from messing with each other..

yes it works fine as separated process

mystran · Post by **mystran** » Wed Jul 31, 2013 11:42 am

tico-tico wrote:yep
First-chance exception at 0x5e0aac25 in reaper.exe: 0xC0000005: Access violation writing location 0x00000000.
and it works without crashes with attached debugger

Actually not always... actually right now it appears to be working for me, with or without a debugger no matter what I do.. which is totally weird.. because earlier it was easy to get crashes.

Like I said, I did manage to get an exception (with attached debugger) in my code trying to restore OpenGL context. I'll keep looking at it though. Maybe there's some corner-case that I'm not being careful enough with.

edit: for whatever reason, can't reproduce it anymore.. I don't understand.. it was crashing, and then it stopped doing it, and now runs fine

tico-tico · Post by **tico-tico** » Wed Jul 31, 2013 2:54 pm

I've replaced old "atioglxx.dll" with a new one (v 6.14.10.11672). Now everything is pretty stable, no more crashes.
Sorry for bothering you.

mystran · Post by **mystran** » Wed Jul 31, 2013 4:07 pm

tico-tico wrote:I've replaced old "atioglxx.dll" with a new one (v 6.14.10.11672). Now everything is pretty stable, no more crashes.
Sorry for bothering you.

Yeah well thanks for reporting it anyway.. helps me keep track of where there might still be bugs (or "compatibility problems") lurking.. and like I said I did notice some odd crashes with NVidia too at first... but glad if a new driver helps.

mystran · Post by **mystran** » Mon Aug 05, 2013 7:29 pm

I wonder, would you people prefer slight CPU hit for full interpolation (well, enough to eliminate clicks), or rather just have it as easy on the CPU as possible?

DuX · Post by **DuX** » Mon Aug 05, 2013 10:49 pm

I will always prefer full interpolation to eliminate clicks, but it does depend on how much CPU we're talking about here?

Now, Dust is using very reasonable amount of CPU, and if the consumption goes up about 30-40% I personally wouldn't mind. Quality is more important in that case, IMO. But if we're talking 100% or more of higher CPU consumption... that would be a bit too much for a tracking EQ in my book.

Just my 2p.

btw, Mystran, your EQ has become my go to EQ now. I simply love it. Sweet sounding, and so neat, fast to work with [GUI]. Brilliant.

A.M. Gold · Post by **A.M. Gold** » Tue Aug 06, 2013 1:21 am

I agree, higher CPU is ok if the sound justifies it, but it's a matter of how high the CPU is---is it impractically high or is it manageably high?

mystran · Post by **mystran** » Tue Aug 06, 2013 11:44 am

Ok, so I implemented basic smoothing (my usual adaptive scheme would be a bit too costly for this, unfortunately) in such a way that it uses the "no-smoothing" fast-path when there's not been any parameter changes since half a second (which is kinda excessively long, but whatever). I've also changed the filter structure slightly, so it should automate smoother in general.

Currently, on my Sandy i7-2600k with 6ms ASIO, if I put 8 instances in series (to prevent multi-core) I get about 4% on FL audio load when they are idle, and a bit more if there's automation going on, so I think it should be reasonable, but please cry if it isn't.

In any case, for "static" EQ this should run approximate the same as the previous versions.

Uploaded 1.6.1 with all the new crap..

http://www.signaldust.com/files/eq-beta.zip

mystran · Post by **mystran** » Tue Aug 06, 2013 11:49 am

Oh crap, there's a glitch with resets with that version. Will fix in a moment.

edit:

Uploaded 1.6.2, fixes the "warmup" glitch on reset in 1.6.1.. which would have been annoying on playback start in hosts that reset on transport

PS: note that "bypass" switch is not smoothed, and this is intentional

DuX · Post by **DuX** » Tue Aug 06, 2013 12:23 pm

On my "Phenomenal" PC it now uses about 50% less when it's static, and about the same as before when I tweak the controls. I think that's more than acceptable!

Gosh it works so smoothly when you tweak the controls. It feels like a real hardware EQ. Smooth as a buttah!

No matter how good an EQ is, if it crackles when you tweak it, it can be sooo annoying, isn't it? You try to pinpoint the frequency, listen to the changes in sound, and you hear the crackling also. Not a really great "feature" of any EQ.

Thank you for the great update, Mystran!

Dust Equalizer