Ugly glitches with sfz-player by "rgc audio"

[Reincke]

I really appreciate using the sfz-Mappings of "pljones" (thank you, Mr. Jones) for the Jazz-Funk-Kit. In my recent session I noticed some glitches on the drum track. I tried to isolate this problem, hoping someone can tell me the reason. And this is how you can easily reproduce it:

open a new session in MuLab
replace the basic synth by "sfz.vst" (2006 version or 1.9.7) by "rgc audio"
inside sfz load pljones' mapping named "GMSW-jazz_funk_kit.sfz"
(you must have downloaded the "Jazz Funk Kit" samples)
create a new sequence with 4 bars
place some notes (length 1/2 bar) at key G2 and A2 (toms)
select the "dry" drum set (without carpet) by hitting A#1
enclose this sequence with loop markers
keep tempo unchanged at 120 bpm
hit "Play"
listen to the occasional occuring glitches at the very start of a tom sample

I checked the samples - they're ok. With "Microsoft Soundmapper" instead of "ASIO4ALL" there are glitches too, same prob. I reduced the number of cores to 1 in audio setup - same prob. With "sforzando" instead of "sfz.vst" there are NO glitches. You might say sforzando is the solution - but shouldn't it work with "sfz.vst"? (Despite that sforzando has probably a problem with "xfin_xxcc#" command, which I use in a derived mapping.) Or is it a prob inside MuLab in combination with the sfz.vst? Please

And this is my configuration:
Intel Atom N450 1,67 GHz (2 virtual cores)
Windows 7 Starter
MuLab 6.2.6
ASIO4ALL 2.12 (44.1 kHz; buffer size 2048 samples )
no other applications running, CPU Meter avg=6%, Max=23%

Any idea 'bout the glitches?
JR

[pljones]

Just to check the exact version of the "sfz.dll" file, can you confirm that you extracted it from a ZIP file and that the DLL has a date of "‎15 August 2006 ‏‎12:13" and a size of 671744 bytes?

The original installer version is not compatible with dual core machines and causes glitches, similar to what you're reporting.

[Reincke]

Thanks for your fast reply.
Same size and date here. There is just an offset of one hour, technically caused by time zone, I think.
JR

[pljones]

Yeah, that'll be timezone. Do you get the same issue running sfz.exe (i.e. standalone)?

[Reincke]

Yes. The standalone version produces the same glitches.
And I get the same prob using sfz 1.9.7 and "sfz_reaper" (whatever this is).
Glitches are just 1 frame and are occurring randomly, not predictable.
JR

[pljones]

I'd have to say that pretty much means it's a problem with your system, unfortunately. I've not heard of many people using sfz on an Atom system, however, so can't really comment. If sforzando itself works okay, and there are just a few tweaks to the mapping needed, that's probably the best solution. (sfz isn't ever going to get an update.)

Things to watch for in my mappings are regions resolving to something like "end=-1 sample={anything}.wav", which meant "don't play anything" in sfz. Sforzando doesn't support this syntax (it rejects the region) - it needs "sample=*silence" to get the equivalent behaviour. I used it to mute other regions.

The latest sforzando should have most of the old sfz opcodes in. If you need help with the mappings, probably best to ask over on the Plogue forum for SFZ Programming.

[Reincke]

Thank you for your hints. In the past sfz worked really fine on my atom netbook. I don't know what's wrong with it now. There is an acoustic bass done with sfz in the same session - no prob.
I will test the session on my desktop computer (quad core).
Besides that sforzando is a good choice.
JR

[Reincke]

Just tested the same session on my desktop computer (quad core): same problem! I think it's more a bug in sfz.vst than a matter of weak hardware ressources. Will using sforzando from now on.
JR