I am running a Roland Quad Capture ADC to USB into Audacity for recording. My mic volumes are preset to about max -3dBu up-line from a tube preamp. The Quad Capture preamps are set at minimum (unity gain). The Audacity volume control is not grayed out and is adjustable (I leave it at 100%). I don’t understand what it is adjusting. The input to Audacity is already digital. I hope and can’t believe that it is yet another DAC-ADC in the chain.
The Audacity volume control is not grayed out and is adjustable (I leave it at 100%). I don’t understand what it is adjusting. The input to Audacity is already digital. I hope and can’t believe that it is yet another DAC-ADC in the chain.
I’m pretty sure it’s digital since I don’t think it’s controlling the analog gain in your interface. There is no additional DAC or ADC. I’d leave the Audacity recording volume at 100% and use the analog controls on you preamp or on your interface.
My mic volumes are preset to about max -3dBu up-line from a tube preamp
Unless you’ve got a calibrated 'pro" setup, there’s no defined relationship between dBu and dBFS. And of course, if you are calibrated you can’t touch the level/gain controls on the interface/ADC. The main thing is to make sure you not clipping your ADC.
My concern is that I am already controlling the dBFS output of the Roland ADC, so I thought that the Audacity volume control would (should) have no effect on the incoming data stream via USB and be grayed out since it makes no sense to have a redundant control. I do leave it at 100%. My preamp output is set so that 0VU=+4dBu=-3dBFS on the Roland which should match, in a perfect world -3dBFS on the Audacity meter.
Changing the ‘gain’ of a digital audio datastream is actually changing the resolution of the digitized waveform (i.e., bit depth). Is this done in Audacity before or after the conversion to 32 bit float? If before, it would be unwise for anyone to record at 16 bit depth with the Audacity volume control at less than 100%, since the s/n ratio will decrease significantly, possibly into audible range.
It’s not done in Audacity at all. As Gale indicated, the slider is just an alias for the Windows volume slider.
It’s difficult to give a definitive answers / settings, because the exact behaviour depends on the computer sound system, and that is different depending on the operating system, the audio ‘host’, the sound system settings, the sound card hardware and the sound card drivers. For example, I have an old SoundBlaster card in which it is impossible to completely bypass the DSP chip when playing back through the front speakers, so for the most accurate D/A conversion it is necessary to use the rear speaker outputs - that’s not a general rule, it’s a quirk that’s specific to one particular range of SB sound cards.
In other words, moving either slider makes the same change in the other.
Many USB ports will apply significant positive gain with the Windows/Audacity recording level sliders at maximum, less if the slider is turned down. Whether your device can control this is open to debate.
Audacity captures audio initially as 32-bit float samples, converting to that format if the samples are not received as such, irrespective of Audacity’s Default Sample Format.
Unless you are using Windows WASAPI host in Exclusive Mode, Windows itself will already have converted your samples to 32-bit float before Audacity gets them.
I am using WASAPI in exclusive mode. The Roland ADC output level in dBFS and the Audacity data stream input level in dBFS match precisely when the ‘volume control’ is set at 100%. This is what I expect to see if Windows has no control over the bit depth of the data stream.
To my way of thinking, neither Windows or Audacity should have any control over the bit depth of the data stream when receiving it, any more than either of them does with an imported data file, and the control should be disabled. For example, if the live data stream contains clipped segments, lowering the ‘volume control’ will not remove the clipping, nor should it. Once the file (live or pre-recorded) is received by Audacity, then, of course, the effects added (gain, panning, fading, etc.) will affect the bit depth, relative to 32 bits. That’s OK, and expected.
I assume from your comments that the ‘volume control’ works in 32 bits, even though my exclusive data stream is in 24 bits and upconverted before being displayed.
To my way of thinking, neither Windows or Audacity should have any control over the bit depth of the data stream when receiving it, any more than kHz either of them does with an imported data file, and the control should be disabled.
Windows drivers make everything compatible… For example, you can play a 196kHz, 32-bit floating-point file on any-old cheap soundcard that only runs at 44.1kHz 16-bits. It’s the same philosophy that allows any Windows-compatible printer or video display to work with any Windows application and images of any resolution.
Pros often use [u]ASIO[/u] hardware+drivers+applications which are less flexible and there is no resampling (and maybe lower latency). Audacity (as compiled & distributed) doesn’t support ASIO, and it doesn’t appear that Roland offers ASIO drivers for your interface.*
WASAPI in exclusive mode is similar to ASIO but I’m not 100% sure that it prevents resampling.
\
There is something called ASIO4ALL that replaces part of the “driver stack” and makes your regular Windows hardware “look like” an ASIO device so it works with an ASIO applicatinon. That won’t help here because Audacity is not an ASIO application.
Unity gain at 100% slider level “may” be something the Roland drivers are able to accomplish, but the Windows USB Audio Class drivers typically work very differently.
Again, the Audacity input level slider is merely a mirror to the Windows slider. It does whatever the Windows slider does.
“ASIO (Audio Stream Input/Output) is another method of audio transport which is superior to WASAPI as it bypasses the Windows Kernel Mixer (and the distortion this adds).”
With regard to WASAPI, it goes on to say say that exclusive mode prevents Windows from mixing Windows sounds with the output stream, but that the data still passes through the kernal mixer which dynamically resamples as required. However, this seems to apply only to output. No mention is made of an incoming datastream to an application.
Which question?
Your question about whether there is another DAC-ADC in the chain has been answered - no there isn’t.
Your question about whether Audacity resamples the data has been answered - no it doesn’t.
Your question about whether the gain change is done by Audacity before or after conversion to 32-bit has been answered - neither, Audacity does not change the gain of the input data, though the Windows sound system may change the gain depending on hardware, drivers and settings.
Your implied question “how do I guarantee zero data loss after the A/D conversion by the Roland ADC” has not been fully answered because we don’t know.
I know that with my sound card (Behringer UCA-202) on my Linux computer, using either the ALSA sound card driver directly, or using Jack Audio System, there is no scaling or conversion of the audio data (other than converting from 16-bit to 32-bit float, which is a lossless conversion).
I think that with your hardware, using WASAPI exclusive mode and the gain set to 100%, it is likely that there will be no scaling, but the only way to be sure is to find the relevant documentation from Roland, which may or may not be available. At the end of the day the important question is whether the sound quality of your set-up is good enough for your needs - only you can answer that.
WASAPI exclusive mode, with the sample rate in Audacity matched to the sample rate of the device, and the bit-format in Audacity set to 32-bit float, is likely to give you the best quality possible with Audacity. Compiling Audacity from the source code with ASIO support, or using an ASIO enabled audio recorder should allow you to guarantee no scaling, though I very much doubt that there will be any audible difference in sound quality, and there may be no difference at all (measurable or otherwise).
Gale mentioned that in some cases, there may be positive gain when the Windows gain control (hence the Audacity input volume control) is set to 100%. To test if that is the case, set the gain control to 99% and apply an analog signal that overdrives the input. If 100% = unity gain you should see clipping just below full scale amplitude (at 0.99 linear scale = -0.088 dB).
This is the question that I think is still unanswered.
You mention about Windows applying gain to the stream. Clearly that is not a bit perfect transfer from the Roland ADC to Audacity. I understand why Windows would do this for generic applications, but, as you mention, undesirable and unnecessary clipping could occur and recorded by Audacity in spite of the supplied data being below clipping.
All this is for the sake of knowledge. I am using tube mics and a final chain s/n of about 76dB, so the resampling errors are well below anything audible. That being said, knowing where to place my 76dB worth of dynamic range in the bit-space is useful, so having gain applied without telling me is not helpful. I also use Ableton Live 9 with ASIO and none of the Windows issues, but I like Audacity much better for my purposes.
Certainly the Audacity developer most experienced in Windows audio systems believes that in WASAPI exclusive mode, Audacity can request the bit depth (always 32-bit as described) and sample rate direct from the sound device without Windows processing, and that this applies to input and output.
Even official documentation can be wrong. All Microsoft documentation we had seen suggested Windows DirectSound could only record in 16-bit, but it can record real 24-bit samples and the next 2.1.3 version of Audacity should support that. As far as I understand it, Windows DirectSound Exclusive Mode in Vista and later is not fully exclusive - it does not resample but it does upconvert to 32-bit float.
Certainly if you look at the Windows “Sound” control panel you can see “Default Format: Select the sample rate and bit depth to be used when running in shared mode”, which seems to imply that in Exclusive Mode, those Default Format settings are ignored. I agree this does not necessarily mean that “some” other processing might not be done in Exclusive Mode.
The “solution” is probably to use a direct to drive/disk recorder where you should be able to control (or have a clearer idea) how exactly recordings are made.
A little OT, but still in the “exclusive mode” “mixer bypass” discussion, here is a 25 second audio file of six samples of base noise - three using the Roland Quad-Capture and three using my laptop Conexant microphone. The Roland had no input mic and the output level was set for 0 gain. The Conexant/Windows Gain control was set to 50% to assure a reasonable bit depth. The three Roland samples were simultaneously normalized to -3dB and the three Conexant were normalized in the same manner. Here is the order:
Roland using WASAPI - Direct Sound - MME - Conexant using WASAPI - Direct Sound - MME
Windows will likely do that for a device using built-in USB Audio Class drivers. You would need to ask Roland what they intend to happen with their drivers and your specific device.
I recorded each sample directly into Audacity using ‘exclusive’ mode, Audacity volume control at 100% for the Roland data stream, and the Audacity volume control at 50% for the internal mic. The Roland samples were copied into a single track, then normalized as a group. The same technique was used for the internal mic. The two groups were then copied into a single stereo track. Normalization was used to make the noise easily audible (base noise in the recordings was in the -80 to -60dBFS range).
A direct comparison cannot be made between the Roland (no mic input, just Roland pre-amp noise in the data stream) and the Conexant internal mic (Software Volume had to be set above 0% and thus mic was active, adding some room noise and Johnson-Nyquist noise), except that the spectral content of the noise varies among the Roland and Conexant samples in the same manner, implying that the audio interface choice has a significant effect on the type of noise added to the recording by the computer.