|
|
| rjisinspired |
| Posted: Feb 4 2012, 02:27 AM |
 |
|
Advanced Member
Group: Members
Posts: 1256
Member No.: 20008
Joined: 12-October 06
|
I'm thinking of buying one. Haven't decided between the AT2020 or an MXL990.
Do USB mics, or even headsets, bypass the on-board sound card while recording? |
|
| phaeron |
| Posted: Feb 4 2012, 09:12 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Yes, they're essentially another sound card that you plug in. Just be sure to do some research -- I've heard not so good things about how well USB audio devices work, generally related to overflow/underflow problems.
|
|
| rjisinspired |
| Posted: Feb 4 2012, 11:40 PM |
|
|
Advanced Member
Group: Members
Posts: 1256
Member No.: 20008
Joined: 12-October 06
|
Thanks Phaeron.
I looked up what overflow/underflow is and a lot of the stuff on a page I am looking at which goes over USB in detail is a little beyond me but the idea that I'm getting is in the case of microphones is that of lag being introduced to transmission/data loss?
http://www.pulsewan.com/data101/usb_basics.htm |
|
| phaeron |
| Posted: Feb 11 2012, 08:17 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Something like that.
Basically, the USB sound card and the computer are dealing with a continuous sound stream, but they have to break the audio up into blocks (packets) to send them across the USB bus. This requires some buffering to temporarily hold the packets. The problem is if a packet gets delayed for any reason, like a garbled transmission or the bus being too busy due to traffic from other devices. If the computer is playing audio through the USB sound card, the packets arriving too late can cause the sound card to run out of sound to play and to temporarily stop. This is called a buffer underrun. The opposite situation is where the USB sound card is recording. It can't stop the sound coming in, so if it can't get the packets to the computer fast enough, its buffer fills up and it starts dropping sound on the floor. This is called a buffer overrun. Both cause breakups in your audio.
When these problems are transient, they can often be mitigated by using a bigger buffer, so if there is a temporary problem there's enough sound or empty room in the buffer to cover it. Increasing the buffer size, however, increases the delay between the computer and the sound being played or recorded (latency). Long playback latency in particular is a problem -- if you've ever worked over Remote Desktop and had the Windows beep sound arrive a quarter of a second late you know what this is like -- so the system tries to use as little buffering as possible to keep latency down to the 10-40ms range. Trouble is, sometimes too little buffering is used and then you get crackling in your audio.
|
|
| rjisinspired |
| Posted: Feb 12 2012, 10:55 PM |
|
|
Advanced Member
Group: Members
Posts: 1256
Member No.: 20008
Joined: 12-October 06
|
Thanks Phaeron.
Thanks for going over this. I understand it now.
I use to have a single USB cable for my guitar and trying to go along with my strumming and playing melody on track 2 was pretty much impossible. Delays big time. Reducing the latency made very bad crackle/sizzle distortions in the sound. Afterward I got a Line6 box and the problems were mostly remedied.
|
|
| phaeron |
| Posted: Feb 20 2012, 08:54 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Yup, the cheesy way to fix a buffering problem is just to throw buffers at it, which works but gives you awful delays. Playing audio through the usual method on Windows typically requires 50ms+ of buffering. Some modern TVs have noticeable delay as well in video.
Thankfully, this issue is at least getting some attention in networking circles under the name of "bufferbloat." |
|
