"Software Playthrough" has always been a bit of a clunky work-around on any platform, and more so on a standard Linux install. I'm quite surprised that you ever got it working properly.
The reason that software playthrough is provided is for situations just like yours, where the audio input device is unable to do hardware playthrough. The reason that it has always been a bit clunky is because of the extra work that the computer has to do in sending the data back out at the same time as recording.
The reason that it is particularly clunky on a standard Linux installation is that Linux gives rather low priority to audio, unless you are using an optimised kernel (low-latency or real-time kernel). To make things even worse, the ALSA USB driver is (at least on my computer) a lot slower than the PCI sound-card ALSA driver. Also, software playthrough seems to be slower if you are outputting the audio to a different device to the one that is the recording source.
Out of interest I had a go on my machine, which is admittedly rather ancient and low spec.
Using OSS for playback was just a "no go" - it ran for a couple of seconds then crashed (processor usage was completely maxed out).
Using "ALSA USB" for recording and "ALSA SBLive" for playback, I could just about get it to work, but with occasional glitches every time CPU usage hit 100%.
The data from the USB input can not be cached, as this would cause huge problems for anyone doing multi-track recording as the latency would go through the roof, therefore it is essential that the input data can get from the analogue input, through the A/D converter, through the USB interface, into Audacity, and down onto the hard drive, consistently in real time. Even the slightest interruption to this will cause an audible glitch or drop-out.
If you look at the specifications of more expensive USB audio devices, you will notice that they have very fast USB ports. This is to ensure that at least the first part of the signal path is fast enough and reliable enough. Once it gets to the USB port on the PC however, there can still be problems if there are any bottlenecks (but that's not the audio device manufacturers problem). You will also notice that most of the more pricey USB audio cards advertise "low latency" or even "zero latency" monitoring - this is precisely to avoid problems inherent with software playthrough. (Pro audio gear does not use USB at all - firewire, ADAT, PCI, or some other interface is used instead)
Anyway, back to "USB in / Sound card out" - with a bit of tweaking I could get it to work with a single audio channel (mono). My PC is very old (Pentium III 500 MHz) and the "bottleneck" for me was CPU load. I guess that your computer is higher spec. so you will hopefully be able to get it to work with stereo, but it's certainly worth checking what your CPU usage is while recording. One of the main problems with USB for audio is that throughput depends on the availability of your processor. If the processor hits 100% even for a moment, the USB interface effectively stops and the audio will be interrupted.
Some of the optimisations that I used to get it working (in mono):
* Start with a fresh boot, and check that there are no non-essential processes running.
* Disable the meters. I checked the recording level before I started to record, by clicking on the meter, but once set, I disabled both meters.
* Turn off "Play tracks while recording new one" - this made a modest improvement in performance, and since I was only wanting to record one track I could safely turn this off.
* Generate silence on a track that is longer than the recording will be, then zoom out to the whole track before starting the recording - this prevents the screen from scrolling and thus reduces the CPU load a little.
* Try different sample rates and bit depths - Lower sample rates and bit depths will put through less data, but in some cases the audio device may have a specific setting that it works best with. For myself there was little difference between 44.1/16 - 48/16 - 44.1/24 or 48/24, but by a slim margin 44.1/16 seemed to be a little better.
* For Windows users, turning off Anti-virus software and de-fragging the hard drive can make considerable improvements, but not really applicable on Linux.
Personally I'd like to see Audacity working with JACK, but unfortunately JACK support is very poor in Audacity at present.
If all else fails, you could go back to an old version, but you would probably have to build it from source. Old versions are available here:
http://sourceforge.net/project/showfile ... up_id=6235
