Stereo Tool

Hi,

I'm getting ready to get back in to my amateur shoutcasting and I'm wanting to use StereoTool to process the final output before it goes in to the encoder. But, I'm having a few issues which I will attempt to discuss in as much detail as possible. The system I'm doing this on is actually a gaming class laptop; Core2Duo P8700 2.53ghz, 6GB DDR2, Intel P43/45 desktop chipset on motherboard, discreet GPU. It's a relative powerhouse even if it is 3 years old. It's been the system I'e played with StereoTool on for a couple of years and it's *never* had issues of not having enough CPU

I do my stuff old school; I don't use SAMS or anything else largely because I've never been able to get them to work and always wind up having sync problems with the music and voice-overs. Essentially I use three copies of Winamp with this setup. Two of them are set to shared mode output for cumbersome mixing; that is set in to an external mic mixer so I can mix a microphone directly with the audio. That then runs in to the line-input of a M-Audio Transit USB sound device and is captured by a third copy of Winamp running a line-level plugin and a DSP stacker with StereoTool and Shoutcast running.

This particular laptop has dual discreet headphone output; so before attempting to go live; I did a dry-run having the third winamp ouput to the second audio device. This is where the problems creep in. With StereoTool set to bypass; the audio ouput is clean and my CPU usage is really quite low. So, I know the audio hardware is working. The input latency on the USB card is cranked all the way up as well to reduce error.

The problem is when I seem to enable StereoTool processing with just about *any* preset. I begin to get all kinds of strange glitching noise; similar to jitter problems; except during periods of dead silence I get bits of previous samples creeping in. If I hit reset all audio settings, it clears up; but the moment I enable any kind of effect it begins this glitching issue. I've decreased the amount of CPU the plugin uses down to the minimum of 20% and turned refresh down to 0%; this does not have any effect, there's the same amount of glitching. The one thing I've found will reduce it is changing the latency down to 2048 samples; lower works better but sounds horrible.

Why would this higher latency cause major issues? I ran a similar setup a few nights ago on a slightly newer Gateway laptop with a Core i3-380M processor. There was no major glitching using StereoTool; but the Realtek card was causing it's own popping and jitter issues.

Am I just running a configuration that refuses to work or is there a bizarre problem with StereoTool no one's noticed yet?

*edit: I found this reply on another thread on not exactly the same issue; but mildly similar:
I have not thought about trying to increase the input buffer; or maybe use a better/different line-input plugin. I will give them a try later.*

*update #2: After searching for another line-input plugin; I was unable to actually find one. So the one I'm using that was last updated in 2002 is my only option. I did however find out how to increase the buffer size and number of buffers. This vaguely helped. I maxed it out at 1000 buffers @ 16384 bytes and it reduced some of the issues; but it did not get rid of them. I then tried unloading the DSP stacker and running StereoTool by itself in Winamp. This helped for about a minute; then it was back to sounding very glitchy.

I have a FLAC file of what I'm getting. The first sample of audio is with StereoTool in bypass; the second sample is with StereoTool 7.40 set to 20% CPU usage and latency of 4096; the third and last sample uses the same settings but drops the latency to 2048. http://dewdu.de/stereotool.flac

I've kept a close eye on my CPU usage and it is no where near maxing out either core while this is running; only averaging about 38% usage.*

*update #3: It does it on the Core i3 with nothing else running but StereoTool inside of Winamp. I'm going to assume it just will not get along with the USB sound. I can't resolve the USB sound so I'll have to figure something else out until I get a solid answer as to why it's acting this way.*

@update #3: It almost has to be something in Winamp then. Can you try a different output? (Winamp has several output plugins). Alternatively, what happens if you use the stand alone version of Stereo Tool instead?

Hiccups mean that *something* is interrupting the flow of the audio. Stereo Tool will block this flow while it's calculating - but Winamp's buffer should be big enough to handle that. Hm, could you check Winamp's buffer filling?


Edit: Ow! ow! It could be that it's the input! Can you try playing a file in that 3rd Winamp instead of using the line input?

I haven't tried the stand alone version because I'm not 100% sure how I'm going to then import that back in to Winamp to stream to Shoutcast. If it outputs directly to a sound device; the only way I'd be able to make use of that is to have another computer with a line-input. Neither laptop has line-input and the USB device is the only thing that works.

I had similar results with different output plugins; but I haven't played too much with the WASAPI as it's buggy. It's also doing this when using a null-output. Normally I use the null-output as I don't need to listen to what's being captured (plus the half second delay makes voice overs impossible); but I did this because I got a lot of complaints about popping and other noise in the stream.
Well, the line input allows you to specify buffers, increasing them helps a little. As far as winamp's buffers; the only thing I see is buffer for DirectSound; which I can crank up and down. The audio from the non-processing Winamp isn't affected; I can monitor that at the mixer and it's clean.

Sorry, that was the same response I had when I first fired this configuration up. The background hum is the power supply on the mixer, haven't had a chance to replace the parts, so that's not the issue. I can play a file in the 3rd Winamp directly with StereoTool using the same preset (Bojcha J-Type) and there is absolutely no glitches/hiccups. In fact, this is the first time I've ever had this kind of issue. As I said in the third update; I moved the "third winamp" to a seperate computer so the only thing it had to do was pull from line-in and run through StereoTool. CPU usage never goes above 22% but does the same thing on there too. It's only when using this ancient line-input plugin that it does this. Sadly; there's no other line-input plugin that will capture and send through StereoTool; and I'm not sure how I'll get the stand-alone version's output back to Winamp to send to shoutcast due to the lack of loopback recording in the ShoutcastDSP. But I know it's not an issue with the USB device itself; as the first sample was made the same way with stereotool in bypass and it came out fine; plus the 8 years I've had the thing it's never had a recording issue. It's latency buffer is also cranked up. I might need to turn it down, but I can't see where that would help.

StereoTool is the only thing that acts this way; and as I said, I moved the third winamp to it's own system and it was the same results, and it only does this when using the Line Input plugin. This is the line-input plugin I'm using: http://home.hccnet.nl/th.v.d.gronde/dev/lineinWA2/ - it's the only one I can find that actually captures the stream. The one that comes with Winamp doesn't capture audio but just pass it through a mixer. Like I said, running the standalone isn't an option as I don't know how I'd get it back in to winamp to shoutcast DSP.

*update: The standalone version of StereoTool is able to capture from the USB sound and stream to the second output while playing through the mixer off the first (in case you forgot this laptop has dual discreet headphone output). Good clean sound. This however leaves me the issue of being unable to now get this audio in to the third winamp to send to shoutcast. StereoMix recording doesn't work (anyone who claims it does has obviously never tried it because it's blocked at hardware level). If I can get some old Realtek drivers loaded and get StereoMix to work, this would be a solution. But, it's obvious the problem is with that antiquated line-in plugin; I just have no clue what it could be.*

Try a program like VB Cable (donationware) or Virtual Audio Cable (paid) to transport audio from Stereo Tool to Winamp. You'll need the same input plugin, but Stereo Tool will be running as a separate process.

How:
- In Stereo Tool, select 'VB Cable' or 'Virtual Audio Cable 1' or something as output.
- In Winamp, select the same as input.

Instead of Winamp, you can of course also use any other program that can capture audio and stream it.

I don't like doing the virtual cables because they've never been stable enough for me. VirtualAudioCable just underruns when I try to shoutcast with it; plus I don't own a copy. I haven't heard of VBCable, I'll give a try.


The issue I have with other programs is I haven't found any that actually work with DNAS2, AIMP3 doesn't support Winamp 5.5 API nor does the edcast plugin work. But I'll give VB CAble a try. I just wish I knew more about why that line-input plugin was causing the issues it is; because I'm starting to run too many programs at once to make shoutcasting even worth my time.

I have actually used that line-in plugin myself before I had the stand alone version but I never saw this behavior. Maybe you can try to contact the author - although I don't know if he even knows what he did if the plugin hasn't been updated for 11 years...

I'll have to send him an email and see if he has any idea; he does say he's available for questions.....

VB Cable is actually working great with the standalone version; I can assign that to the shoutcast DSP's line-input function. I've been listening to it's input directly with Win7's "Listen to this device" for about a half hour with processing; not one single glitch. And that's with the standalone version cranked up to 100% CPU while live-mixing from two winamps through WASAPI's shared mode.

Thanks for telling me about that; I don't know why I'd never found it in the past.