Using JUCE 1.46, when I connect the audio input to the audio output in the JUCE Plugin Host application, I get weird echoey stuttering audio. It’s the same when running through a VST plugin, although a VSTi sounds fine.
My sound source is connected to the line in on my laptop, and line in is selected as the input in the Windows mixer. If I turn up the line in fader on the Windows output mixer (i.e. monitoring the input), I can hear the signal just fine, but turning up the Wave fader reveals the trainwreck coming from Plugin Host. Can anyone else make this work?
I haven’t tried compiling the host with ASIO enabled and using a “real” audio card, but I suppose I will do that next…
Yeah, I tried upping the buffer size all the way to the maximum (and everything in between), but it didn’t help.
The stuttering is really more like a “stuck buffer” kind of sound, not just the occasional click or dropout. I’ve seen this on a couple of machines now, although they are both using crappy Realtek sound.
I’ve seen plenty of laptops with realtek cards, but never heard of it doing that before. Not sure what to suggest, really - does the sample rate make any difference?
It sounds slightly different at different sample rates, but it still has the same general problem. I still haven’t had a chance to try it with an ASIO driver.
I’m having the same problem, so there’s clearly something “going on.” I don’t have too much more data yet; I’ll keep trying to pin down details.
What is clear is that the input signal is getting recycled back and summed into the input again after delay, probably a buffer-length long – a simple “tick” becomes a sort of buzz; guitar (for example) accumulates over itself in a most unpleasant manner! It’s definitely summing, rather than just repeating, though the “new” signal (the first time through!) seems okay.
I’m using ASIO and a MOTU interface over firewire, vst2.4, win XP. I’ll keep trying to pin down more details and isolate the issue.
(In any case, as a new guy… Thanks sincerely for everything! I’m looking forward to working with this package.)
I have the strong suspicion that this is related to my old “feedback loops not working” issue… I have to admit that I also didn’t have the time to really investigate this in detail, but there’s definitely some strange things going on when building the rendering sequence. Jules, if you could remember what you intended with the “ReadOnlyEmptyBuffer” that would already be a great help!
The ReadOnlyEmptyBuffer is really just what it says - an read-only empty buffer that can be shared amongst many readers, to avoid the overhead of creating multiple empty buffers that aren’t needed.
Okay, but sometimes it seems that it’s not really “read-only”. For instance, when I have a feedback loop then this readonly buffer is used. When I have an unconnected output, it’s used there as well. From my observation it often happens that what should be in the feedback loop is played at the unconnected output instead (where there shouldn’t be any sound at all)…
