Something's messing with my mic levels

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?

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_recording_troubleshooting.html#enhancements

Koz

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.

FAQ:Recording - Troubleshooting - Audacity Manual

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

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.

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

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.)

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

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.

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

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.

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.

I am the main “WIndows elf” here. So you already heard from them.


Gale

You did not give the entire error. If it says that the problem is with playback, then probably you need to make Windows Default Format playback the same as Audacity Project Rate (Exclusive Mode off) or choose a project rate that is a sample rate supported by your playback device (Exclusive Mode on).

And you must restart Audacity after making changes in Windows Sound, or you will get WASAPI error opening in any case.

Under DirectSound on Vista and later, even with Exclusive Mode on, Windows will always upconvert to 32-bit float before Audacity even gets the audio. DirectSound (and MME) are emulated on top of WASAPI on those versions of Windows.


Gale

I am not suggesting anything. I am telling you that Audacity always records in 32-bit float. Look at the Audacity source code if you don’t believe it.

So yes, if you change to 16-bit quality in Audacity then your recording will be downconverted to 16-bit and dither applied (unless you turned dither off, which is not recommended). As you’ll know, there are many advantages to processing in 32-bit float.


Gale

I might have to, but dual boots are a pain, and I have Windows programs I need to run. For that matter, it would be a pain to migrate the macros that make Audacity dance for me over to a different program that runs in Linux. (I actually have a close approximation of punch-and-roll running with Audacity.)

You did not give the entire error. If it says that the problem is with playback, then probably you need to make Windows Default Format playback the same as Audacity Project Rate (Exclusive Mode off) or choose a project rate that is a sample rate supported by your playback device (Exclusive Mode on).

In 2.1.2, it usually said “recording device”, but occasionally would say “playback”. I never did figure out if there was a pattern to it.

The message has changed slightly in 2.1.3. Now, the 2.1.3 error reads in full: “Error opening sound device. Try changing the audio host, recording device and the project sample rate.”

And you must restart Audacity after making changes in Windows Sound, or you will get WASAPI error opening in any case.

Even if you “Rescan Audio Devices”?

Restarting Audacity doesn’t fix it at any rate.

Under DirectSound on Vista and later, even with Exclusive Mode on, Windows will always upconvert to 32-bit float before Audacity even gets the audio. DirectSound (and MME) are emulated on top of WASAPI on those versions of Windows.

Ok. So, is there any way to determine which filters/transforms/algorithms Windows is applying, and does it do so before or after converting to 32 bit? (presumably after, but I’m not assuming that it only adjusts volume; you can’t always trust MS not to do something dumb.)

As you’ll know, there are many advantages to processing in 32-bit float.

Yes, I agree there. I’m not concerned about the conversion to 32 bit. I’m concerned that something is adjusting the actual values in the signal. I want to know what it’s doing (preferably why), and whether or not I’d benefit from stopping it.

I was much more concerned when I thought that it was Audacity that was upconverting to 32 bit. That would have meant definite loss of fidelity. Now, It’s uncertain. It depends on whatever other voodoo is going on where I can’t see it.

Do not use Windows if this matter concerns you. Of course with specific USB devices that have custom USB drivers it is possible there will be no scaling if the drivers are written that way. You cannot guarantee no scaling with a device that uses standard Windows USB Audio Class drivers.


Gale

As stated, upconversion to 32-bit float will happen with DirectSound host before Audacity receives the audio.

If you use WASAPI Exclusive Mode (if you could get it going) then Windows should be handing 16-bit audio to Audacity and it will be Audacity that does the upconversion to 32-bit float on capture.


Gale