Jerky rendering of sounds

Official support for: zynaddsubfx.sourceforge.net
Post Reply New Topic
RELATED
PRODUCTS

Post

Hi,
I've been using ZynAddSubFX under VSTHost; I'm very keen on it because of its ability to use alternative scale tunings.
I've always notice some burbles or other discontinuities when I play a bit on MIDI keyboard; now I am trying to make some example recordings to accompany an academic paper on earlier tuning systems. I use one of the supplied organ sounds, and I am playing back various MIDI recordings (Bach chorales at the moment). I cannot get a clean result, even on a freshly booted system (XP Pro, and I tried also on a newer, Win 7 Pro machine) where I have even removed some utility programs that might draw CPU time. Even a simple, slow monophonic scale might not come out clean if I am moving the mouse, for example; and the four-part harmony examples are quite poor. When I examine CPU usage under ProcessExplorer or Task Manager, VSTHost never shows much usage, never above 1%. It can show System Idle Process almost 100%. This doesn't make sense, why the software isn't using much CPU when it is trying to do large calculations and get the results to the output. I also tried boosting the task Priority and heard no difference. I wonder where the problem lies; I can't imagine everyone using this software gets this poor sound and continues to use it, so I hope there are some suggestions about how I can make this work.
I thought to try ZynAddSubFX under a different host but I'm not having much luck either.
I'm really stumped (and I have little other experience with MIDI). I do get a smooth rendering with the program Anvil Studio, which I was using to edit these chorale MIDI recordings; but I need the scale capabilities (excellent feature) of ZynAddSubFX.

Hope there is a solution.
Thank you very much,
Michael
Michael

Post

Well, Just now I've now succeeded in using Minihost as the VST host; and in this case it seems to give excellent results. So I am set to proceed with my work; but if anyone has any idea why it simply got so constipated under VSTHost, I would certainly like to understand that. Something peculiar about my own installation? Something that many plug-ins encounter with VSTHost? A mystery?

Many thanks,
Michael
Michael

Post

Hi Michael,

What version of VSTHost are you using? What version of Zyn?
What soundcard drivers are you using (this is the performance driving factor, not CPU power)? what kind of soundcard do you have?

If you're not playing in realtime but rather rendering something (and latency is not an issue for you) try to increase audio buffers, both for your audio drivers and Zyn's internal buffer size.
== VDX == One Man can make a difference!
My music is on https://soundcloud.com/vdxi | Info | More Info

Post

Hi Paul,

I've got Zyn 2.4.1.480beta. Guess I haven't updated that.
VSTHost I was running 1.4something, then before posting on this I downloaded 1.54 but did something wrong in installing it and now it blows up immediately on loading Zyn.
I have E-MU 0202 and its ASIO drivers. As you say, when rendering a file latency is not an issue; I've also tried this with the built-in laptop SoundMax HD driver, with and without ASIO4ALL v.2

But of course I also want to play from MIDI keyboard; so I definitely use E-MU when doing that.
[I haven't found a way to get external keyboard to play through MiniHost - perhaps it isn't designed to do that? plays sounds from the MIDI file, and the virtual keyboard, but I haven't found a way to get it to react to the MIDI-keyboard].

I looked up the current settings in Zyn internal buffer - it is set at 512.
I've made various experiments in changing the ASIO buffer - don't believe I thought about finding this Zyn buffer.

Perhaps I will have time to try some more experiments on Monday.

Thank you for everything,
Michael
Michael

Post

Hi Paul,
I do not think what I am experiencing is tied to driver. What I experience is - the more complex the input, (i.e. four-part harmony vs. a simple scale), the more damaged, and even jerky, the output. Now, once the sound has been rendered by the synth, the wave data sent to the driver is the same size, i.e., so many data points; regardless of the number of simultaneous notes the result is x amount of data, and the transmission of that to the driver, and the driver's transmission of that to the D-A converter, is the exact same amount of work, whether it is a complex wave, a simple wave, or silence.
In this case, the complexity of the input causes more degradation of the sound; so it seems to me it has to take place in the rendering.
I have zero knowledge of all the wonderful things that are done in synthesizing sound. But I think I have a general sense of the different compartments of the path of work. Am I missing something?

Thanks again,
Michael
Michael

Post

Hi Michael,

I am not Paul, I did not write ZynAddSubFX, I only made the port from native linux to windows VST :)

Please update to 496beta (480 had a nasty memory leaking bug which could cause the hosts to crash).
You can find the link here: http://www.kvraudio.com/forum/viewtopic ... 7&t=268277

I think the problem is usually tied to the driver. In this case it could be something either with VSTHost or Zyn dll.

ZynAddSubFX VST is 32bit. Are you using VSTHost as a 64bit host? or are you using any bridge from 64bit to 32bit?
please use this verion (x86):
http://www.hermannseib.com/programs/vsthostx86.zip
and not the 64bit version (x64).


The more complex the input, the more notes Zyn has to process. I imagine that the reason for the jerky output is some buffer over-run.
To have an output, the synth has to calculate <sample_rate> samples per second (usually 44100 samples per second. What sample rate are you using?)
For transferring samples a buffer is used. Every time the host asks zyn to output something, it calculates <Zyn_internal_buffer> samples. Your soundcard driver also delivers data to the AD converters using a buffer (usually the ASIO buffer). To have the least overhead, it should be ideal that the internal zyn buffer is the same size as the ASIO buffer so that when the asio buffer needs to be filled only one call to zyn is made.
However, Zyn doesn't function correcly if it's internal buffer is below 256. This is an internal limitation. So my first idea is to try both ASIO size and internal zyn buffer to 256 samples. See if that works for you.
The latency is the time needed for the host to ask for one single buffer, so in case of 256 buffer size (assuming 44.1k sample rate):
latency = 256 / 44100 = 5.8 [ms]

This should be enough for playing a keyboard and a synthesizer.

Now every 5.8 ms, the host asks zyn to compute a new buffer (256 samples). Depending on how complex the input is your cpu must be able to compute all the voices and mix them and then send these 256 samples to the AD converter. If for some reason the samples don't reach the AD converter in time the output is jerky. Usually something bad happens when the soundcard driver is unable to send the buffer fast enough, but if the input is more complex, more time is used calculating (mixing) the output samples and less time is available for the driver to transfer the samples to the AD converters.

If your ASIO buffer is not a multiple of the internal zyn buffer (or the other way around), that could also be a problem because the cpu needs to make extra calculations.

If setting both ASIO and internal buffer to 256 doesn't work, try both to 512.

I have to try the latest VSTHost in combination with Zyn 496beta on my own machine with ASIO drivers to see if I have any issues.
== VDX == One Man can make a difference!
My music is on https://soundcloud.com/vdxi | Info | More Info

Post Reply

Return to “ZynAddSubFX”