Something's messing with my mic levels

[gd2shoe]

I'm using a Blue Snowball (16 bit, 44.1 kHz, USB mic). With software volume turned all the way up, I get clipping, but with software volume turned down, I don't. Since the mic is only providing a digital signal, this means that something between the mic and Audacity is boosting the volume, and is probably losing information or inserting artifacts (not that I've heard them, yet).

I don't think Audacity is the problem. Rather, I think it's a driver or Windows subsystem that's trying a bit too hard to be helpful. There is no "boost" setting for this mic in the "Sound -> Recording" tab. I would like to get the sound from the USB into Audacity unmolested. I can tweak it there (normalize, compress, etc). Any ideas where I should start looking?

[kozikowski]

I'm using a Blue Snowball

...to do what? Podcast? Sing?

It's not unusual for Windows to have conference and communication processing to force your voice to be loud and dense, sometimes whether you want it to be or not. It can also have environment and echo processing.

http://manual.audacityteam.org/man/faq_ ... hancements

Koz

[gd2shoe]

I'm using a Blue Snowball

...to do what? Podcast? Sing?

Narrate, but does it matter?

It's not unusual for Windows to have conference and communication processing to force your voice to be loud and dense, sometimes whether you want it to be or not.

And that can be found where? The communications tab only has an option to "Reduce the volume...", which is already set to "Do nothing".

It can also have environment and echo processing.

http://manual.audacityteam.org/man/faq_ ... hancements

Koz

The built-in mic has an "Enhancements" tab and a "Noise Suppression" option, but the Blue Snowball doesn't even have the tab. There's no "Noise Suppression" or "Echo Cancellation", or other enhancements to turn off. Neither playback nor recording have an "Environment" anything that I can find on any tab, let alone speaker->enhancements.

Since I forgot before: Windows 10, Audacity 2.1.2

[kozikowski]

Narrate, but does it matter?

It could. Straight narration can fall into the processing sweet spot. It levels out your voice and suppresses echoes and room noises. If you're not too picky about the compression artifacts, it can actually help.

But you're right. Most USB microphones record low volume on the theory that low volume is a minor annoyance, but overload and clipping is immediately fatal. Only overload causes you to send the microphone back.

I understand that some machines automatically boost USB sound volume to make up for low microphone volume...and round and round...

I'm out. We should wait for someone more familiar with the Windows settings.

Please note that Audacity 2.1.3 is available. It solved a number of 2.1.2 problems.

http://www.audacityteam.org/download/windows/


Just reading over that again, are you confusing normal, graceful narration recording with commercial production or possibly broadcast volume? It's not unusual for commercial products to be compressed and boosted and you're never going to walk away from a straight reading with a dense, loud voice.

Are you reading for AudioBooks? There's a whole ACX protocol and test process for that. You are expected to read several dB lower than delivery volume. Nobody reads straight into an Audio Book chapter.

Koz

[gd2shoe]

If you're not too picky about the compression artifacts, it can actually help.

I'm picky about any artifacts that can be heard. I won't know if what-ever-this-is adds noticeable artifacts until I can get it to stop. I know something is messing with lower frequencies, but I think that's a separate combination of factors (not solvable here). But if this thing is inadvertently skewing the equalization, it could be exaggerating that issue. I'm also getting some reverb in lower-mids that I think are sympathetic vibrations in the recording space, but those could conceivably be a type of artifact. I don't know if chasing down this anomaly is going to make either of these problems better or not. The only way to find that out is to record without it and hear the difference.

As an aside, I've listened to plenty of podcasts with terrible compression artifacts, and no, those aren't welcome in any of my current projects (or my foreseeable ones).

I do care about loss of quality. I could crank the mic down to 25% and never get any clipping (even if I yelled), but I'd effectively be chucking 2 bits off a 16 bit signal. Going the other direction, upping the mic level, and clipping is definitely an artifact to be avoided.

Are you reading for AudioBooks? There's a whole ACX protocol and test process for that. You are expected to read several dB lower than delivery volume. Nobody reads straight into an Audio Book chapter.

Among other things. And yes, I'm aware that the mic will be quiet (hypothetically), and will need editing, normalization, and compression, etc (and that converting to 32-bit before processing may cause less signal loss during transformations, etc). But I need to get the actual data coming from the actual mic into Audacity cleanly. Then I can futz around with production. I don't want data lost before I even begin, and I don't trust random anonymous algorithms not to do stupid stuff. This is akin to recording using a mixer board that has developed... personality. The raw take should be as clean as reasonably possible.

Please note that Audacity 2.1.3 is available. It solved a number of 2.1.2 problems.

If I must, I will. I've got a number of customized settings that work with customized macros. An in-place upgrade would probably go smoothly, but it could be a royal pain to debug.

I don't think this is an Audacity bug to be fixed, but I was thinking that maybe there was a setting somewhere that could be used as a work-around and/or that someone here may have dealt with similar problems before. As such I really don't expect that upgrading will make this go away. (I glanced through the release notes, all the same, but I don't see it.)

[Gale Andrews]

I'm using a Blue Snowball (16 bit, 44.1 kHz, USB mic). With software volume turned all the way up, I get clipping, but with software volume turned down, I don't. Since the mic is only providing a digital signal, this means that something between the mic and Audacity is boosting the volume, and is probably losing information or inserting artifacts (not that I've heard them, yet).

I don't think Audacity is the problem. Rather, I think it's a driver or Windows subsystem that's trying a bit too hard to be helpful. There is no "boost" setting for this mic in the "Sound -> Recording" tab. I would like to get the sound from the USB into Audacity unmolested. I can tweak it there (normalize, compress, etc). Any ideas where I should start looking?

Then don't use Windows because there is no way to configure the gain that USB ports apply. But you might find less gain on a different USB port.

Also if you want "bit perfection" you won't be able to get that in Audacity on any operating system because it always captures at 32-bit float (that is, upconverts the bit depth).

You can get closest to "bit perfection" if you use Windows WASAPI host in Audacity and enable both Exclusive Mode boxes for the Snowball (Windows Sound, Recording tab, Advanced properties for the Snowball).


Gale

[gd2shoe]

Then don't use Windows because there is no way to configure the gain that USB ports apply. But you might find less gain on a different USB port.

USB ports don't apply gain. They provide 5 V and at least 0.5 A. There may be inaccuracy in voltage, but only slightly. Adjusting the volume control on a USB mic does not adjust voltage on the USB interface. That's a lot like saying that trying a different Ethernet port may affect the gain on Pandora or Spotify. It's all digital data at that point. The first part of the system that even notices that a sound device is plugged in is the software driver. That's where USB mics start to diverge from mice and printers.

Also if you want "bit perfection" you won't be able to get that in Audacity on any operating system because it always captures at 32-bit float (that is, upconverts the bit depth).

Are you suggesting Audacity always converts to 32 bit float, and then converts back down to the quality setting? I don't know enough to argue against that, but it seems illogical.

At any rate, up-converting to 32-bit shouldn't be a problem. In over-simplified terms (int->float), it adds a bunch of zeros to least significant digits. It's like recording bank transactions, but adding five zeros after the penny. It looks funny, but doesn't change the actual amount of money that changed hands. I've experimented with taking clipped audio from 16-bit tracks and converting them to 32-bit tracks. They're still obviously clipped, even if I deamplify them a bit first. I intend to do my work in 32 bit anyway to limit the effects of rounding error propagation until the final export.

So, in short, I have a 16 bit original signal, which get's increased in volume for some unknown reason, and which I need to turn back down again. This results in a signal that is technically 16 bit, but only carries 14 bits of sound data (and unknown artifacts or processing). Audacity then up-samples to 32 bit, which is still carrying 14 bits of sound data. (Even this is oversimplified, because where the actual data loss is going to occur is during rounding issues in amplification.)

You can get closest to "bit perfection" if you use Windows WASAPI host in Audacity and enable both Exclusive Mode boxes for the Snowball (Windows Sound, Recording tab, Advanced properties for the Snowball).

Good to know. Doesn't change anything experimentally, but I'll keep it in mind.

[kozikowski]

USB ports don't apply gain.

Some apparently do. We've encountered several instances where changing the USB port was enough to solve overload and volume problems not attributable to straight 5v misbehavior. As you say, that should be impossible.

Are you suggesting Audacity always converts to 32 bit float... but it seems illogical.

Audacity is immune to the problem of accidentally applying effects or filters that cause a positive gain by accident. If we didn't do that, the first time you caused some portion of the show to go above zero, you'd be dead. That portion would be lost. The down side is the eventual desire to produce a 16-bit show and then yes, you'd have to carefully downconvert.

get's increased in volume for some unknown reason

Right. You're the poster child for a Windows machine trying to "help you" with your show. I did an evaluation of a Windows machine and somebody upstream left one of the internal effects running by accident ... and didn't tell me. Took us a while to nail that one down, it did.

We'll see what the Windows elves think.

Koz

[gd2shoe]

USB ports don't apply gain.

Some apparently do. We've encountered several instances where changing the USB port was enough to solve overload and volume problems not attributable to straight 5v misbehavior. As you say, that should be impossible.

Possibly a bad port, not supplying sufficient voltage? Or a bad mic, drawing more current than it should? Or even a faulty power supply? Hmm...

Are you suggesting Audacity always converts to 32 bit float... but it seems illogical.

Audacity is immune to the problem of accidentally applying effects or filters that cause a positive gain by accident. If we didn't do that, the first time you caused some portion of the show to go above zero, you'd be dead. That portion would be lost. The down side is the eventual desire to produce a 16-bit show and then yes, you'd have to carefully downconvert.

I don't think I got my point across clearly, but no matter.

I've done a bit of reading today about Windows' audio stack. Apparently WASAPI upconverts at some point to 32 bit float. If I could reliably use WASAPI, and if the ONLY thing it's tweaking for me is a volume boost AFTER converting to 32 bit, that would be OK. I would still want to know what's going on so that I can be sure no other filters are being applied (If I could use WASAPI). Anybody know if Audacity opens WASAPI in raw mode? (If I understand...)

At any rate WASAPI is currently useless on my system. It will not record a second track if I've already got one. ("Error opening sound device..." no matter what I've tried.) Grrrr.... I've already tried everything I can think of, and gone through that part of the online Audacity manual.

I'm not sure if DirectSound upconverts, or delivers 16 bit. It's old enough, I suspect it doesn't, which would be back to my initial concerns. (seeing as I'm currently stuck with it)

I did end up upgrading today to 2.1.3. (The pinned playhead is neat, btw. Big improvement.) I discovered after the upgrade that scrubbing in WASAPI causes the program to lock up (Infinite "Error opening..." msg boxes), and needs to be killed.

We'll see what the Windows elves think.

Fingers crossed.

When they show, in case it matters (unlikely): the soundcard in this laptop is Realtek, and I think the driver getting applied to the Snowball is C-Media.

[steve]

Perhaps you should consider migrating to Linux.
The sound system on most modern Linux systems is a low level "driver" layer called "ALSA", with a sound server called "PulseAudio" above it. Audacity allows you to select the low level ALSA device OR the higher level PulseAudio sound server. The standard USB ALSA drivers do not apply scaling to the input stream from USB devices, so this is the option that you would select to avoid digital scaling from a USB device.