I use a SoundBlaster Play! 3 to record from an external analog (mono) audio source. This interface can sample in 24 bits at 48kHz. When I run Audacity from my Mac this is configured via the “Audio MIDI Setup” program. I don’t see how to do this on Linux, and I haven’t found a succint explanation from the obvious internet searches either (lots of irrelevant hits).
I have Audacity 2.2.2 provided through the distro (Devuan Beowulf), which only allows me to select the SoundBlaster interface via ALSA. I have to presume that the interface will be set to 48kHz when I set the Audacity project to that sampling rate, but I see no way to specify the bit depth at which to sample.
With Audacity’s default settings, if the ALSA drivers send 24-bit samples to Audacity, then Audacity will record the 24-bit data padded to 32-bit float.
If the ALSA drivers only produce 16-bit samples, then Audacity (with default settings) will record 16-bit samples padded to 32-bit float.
Audacity works internally in 32-bit float, so it’s best to keep the default recording settings as “32-bit float”.
I don’t. I’m on a Mac and I do everything at 16-bit. I’m tempted to dig into theory and find a way to determine the bit depth around the barn instead of watching settings and indicators, and I couldn’t do it. 16-bit, someone will correct me, gives 96dB range which is far and away more than anyone is likely to ever use, and is more than most if not all home equipment can manage.
I don’t think the 24-bit specification came from Engineering. I think it came from Promotion and Publicity. “We have to claim that because the next device over is claiming that and we have to keep up.”
As I pointed out earlier, there’s a utility called Audio Midi Setup on Mac which allows you to set up audio in and output devices, including bit depth on supported devices.
16bits gives you 64k discrete levels which is indeed good enough for almost all applications and circumstances … for the final result. For the initial acquisition and the intermediairy processing it is beneficial to have more headroom - just like you’d use a higher sampling rate and you don’t save your project in a lossy format. Recording in 24bits makes it safer to record at a safe volume (peaks at -6 to -3dB, thus avoiding clipping) and then amplify it to use the entire range without increasing the silence threshold, for instance (before saving as a 16 bit track).
I didn’t know this either when I started recording my playing, but I’d say I can hear an improvement - after I applied the above knowledge which I got from a sound engineer.
I’ve not tested because I don’t have a 24-bit audio device, but my understanding is that on Linux, if you have a 24-bit device with fully functional ALSA drivers, then the device will work at 24-bits automatically - no configuration of the sound system required.
if you have a 24-bit device with fully functional ALSA drivers, then the device will work at 24-bits automatically - no configuration of the sound system required.
How would you check that? The goal is to avoid time bombs—failures that happen later because of an earlier mistake.
MP3 comes to mind.
This would also be a terrific place to have Audacity Get Info.
If you can hear the difference between a 24-bit recording and a 16-bit recording, just make a test recording, play it back and listen.
If you can’t hear the difference between a 24-bit recording and a 16-bit recording, then why would it matter?
See my post above. The question also is: why would you risk to hear that you didn’t get the quality you want? And do you seriously think that consumer grade devices would offer the choice of bit-depth if there were no point?
If yours is the official standpoint of the Audacity team I’m quite disappointed in what is clearly a lack of interest to provide a tool that’s also suitable to be used for professional applications (and it makes you wonder why Audacity would bother to work with 32bit float precision internally). I’m not a pro myself, but when I record something I do want to get the best possible result.
I dug through some more online resources, and found a suggestion that you cannot set these ALSA parameters via configuration files. Using one of the alsa tools (arecord), you specify them on the commandline (–format for bit depth). This in turn suggests that Audacity could (and probably should) control the recording format itself. It would be fine with me if that were done via “let’s use the best possible format we can get from the chosen device”.
Re: Providing a Get Info: that would have to be useful as a tool but would have to be something you can invoke from the open/import dialog. Because once a file has been imported/opened it becomes a project and I don’t see evidence of the existence of a log of all imported files with their exact formats. Could be useful though.
You’re reading too much into my last (tongue in cheek) reply.
As I wrote in my comment before that - as far as I’m aware it works automatically on Linux when using ALSA (or Jack), and you only need to make manual configurations if you choose to use PulseAudio.
Looking at the code, it seems that Audacity asks for captureFormat = floatSample (32bit float) format, overwritten by captureFormat = mCaptureTracks[0]->GetSampleFormat() if there are tracks already, in AudioIO::StartStream(). Sounds like the selected preference may not actually be used so we’re still left with the question what happens if the audio device doesn’t support 32 bit float.
it makes you wonder why Audacity would bother to work with 32bit float precision internally
Because it doesn’t overload.
It’s not unusual to apply filters, effects, or corrections that temporarily cause sound volumes to go higher than 100%. In a strict fixed-precision system, those areas would become permanently damaged.
The problem is not odd or unusual, either. The Audacity Audiobook Mastering Suite corrects rumble first. Then it forces RMS or loudness. That one step frequently produces spikes and events louder than 100%. Then Mastering applies Limiter to gently and gracefully reduce those loud areas to satisfy the audiobook Peak requirement. That wouldn’t work without 32-floating.
It could be said if you can hear the difference between 16 and 24 at the recording stage, there may be something broken.
Sounds like the selected preference may not actually be used so we’re still left with the question what happens if the audio device doesn’t support 32 bit float.
Audacity converts to 32-float no matter what the device supports. See my above explanation. It then “deconverts” back down to non-floating at the Export step if that’s what you set it to do.
Audacity gets its sound from the computer’s drivers and processes, not the microphone. So it may be possible to get two conversions.
If an app requests a higher sample format than the sound system can provide, the sane thing for the sound system to do would be to provide the highest sample format that it can. Why do you think that ALSA doesn’t do that?
Perhaps we need to take a step back - Are you able to record 24-bit data on Linux with your setup?
