Audacity Forum

Hello,

I have some points to ask:

1. How to be sure the setting "Recording: Audio to buffer" has a safe value? I experimented when it is too low, it does not start the recording (it is written on your help page too). But I experimented also when I start the recording, it can be blocked quickly, then it starts. That is why I wonder if the recording can be blocked or something similar and start again "as he wants". And if yes, how can I detect this if I record for 30 mins for example? There is a blank sound or something similar? Or I need to listen fully and detect by myself?
2. Can you explain more precisely how work the setting "Recording: Audio to buffer" when recording? In comparison to the playing, it is maybe silly, but I thought to see the sound recorded around 5 seconds later like the playing mode does (if "Audio to buffer" = 5000ms), instead of seeing the wave sound instantly.
3. What is the value of the setting "Recording: Audio to buffer" when WASAPI is selected? 10ms (I read it is the default value in Windows, but I do not know if it is true), or other? Related to the first point, it will be possible to up this value when this setting will work for WASAPI?
4. Quoted from https://msdn.microsoft.com/en-us/window ... -audio#FAQ : "In summary, each application type has different needs regarding audio latency. If an application does not need low latency, then it should not use the new APIs for low latency."
   → My conclusion: Use MME (in Audacity) instead of WASAPI if you want the "best quality", is it true?

Moved to the correct Windows board.


Gale

Why is "Audio to buffer" such a concern for you? Are you doing overdubs? If not, I suggest leaving the setting on the default 100 ms. As you noted, the setting has no relationship to how soon the waves are drawn on the screen.

As it says in the 2.1.3 Release Notes, "Audio to buffer" cannot be used to adjust recording latency using WASAPI host.

If you are recording with "Software Playthrough" on, the buffer is at a fixed setting depending on the host choice, and changing "Audio to buffer" will have no effect.

It is impossible to generalise that MME gives better quality than WASAPI. It depends what you are recording and what audio devices you are using and what drivers those devices have. You gave us no information about that. Older devices may quite conceivably work better with MME or Windows DirectSound but on Windows Vista and later those two hosts are still emulated on top of WASAPI, and so go through WASAPI.


Gale

Kdmeizk wrote:Hello,

I have some points to ask:

1. How to be sure the setting "Recording: Audio to buffer" has a safe value? I experimented when it is too low, it does not start the recording (it is written on your help page too). But I experimented also when I start the recording, it can be blocked quickly, then it starts. That is why I wonder if the recording can be blocked or something similar and start again "as he wants". And if yes, how can I detect this if I record for 30 mins for example? There is a blank sound or something similar? Or I need to listen fully and detect by myself?
2. Can you explain more precisely how work the setting "Recording: Audio to buffer" when recording? In comparison to the playing, it is maybe silly, but I thought to see the sound recorded around 5 seconds later like the playing mode does (if "Audio to buffer" = 5000ms), instead of seeing the wave sound instantly.
3. What is the value of the setting "Recording: Audio to buffer" when WASAPI is selected? 10ms (I read it is the default value in Windows, but I do not know if it is true), or other? Related to the first point, it will be possible to up this value when this setting will work for WASAPI?
4. Quoted from https://msdn.microsoft.com/en-us/window ... -audio#FAQ : "In summary, each application type has different needs regarding audio latency. If an application does not need low latency, then it should not use the new APIs for low latency."
   → My conclusion: Use MME (in Audacity) instead of WASAPI if you want the "best quality", is it true?

There is an article here you might find useful http://www.soundonsound.com/sos/jan05/a ... cian.htm#1.


Gale

I'm not an expert but I'll share what I know...

There a lot to it, there is a FREE online book about optimizing your computer for audio called Glitch Free. The book is mostly geared toward musicians using a computer for live performance (where latency is important) but there is lots of useful information for recording too.

IMO - The BEST solution if you need low latency (to monitor yourself while recording) is to get an interface with direct-hardware, zero-latency monitoring (where the monitoring signal doesn't go through the computer). Then you can use a big buffer (long latency) and don't worry about it.

Or, if you don't need to monitor yourself while performing & recording you can go-ahead and use a big buffer. The ONLY downside to a big buffer is latency (delay) and in many situations there is no downside to a few milliseconds of delay.

That is why I wonder if the recording can be blocked or something similar and start again "as he wants".

Yes, that's right. A buffer is a "holding tank". When recording, the audio data stream flows smoothly out of the ADC into the buffer. Then when the multitasking system gets around to it, it reads the buffer and transfers the data to your hard drive (or in some cases, RAM) in a quick burst. If the buffer doesn't get read in time, you get buffer overflow and data is lost. (There will be a missing piece of audio). The "glitch" may be heard as a click or pop where the waveforms re-join, or it may just "sound bad" and in some cases you may notice that the playing time is short or that the overall tempo is too fast when you play-back the audio.

The operating system is always multitasking, even when you're only running one application. But, it's "safer" to run only one application while recording, and to minimize background operations. Note that you can get buffer overflow without high-overall CPU usage... If some application/driver "hogs" the CPU/data bus for a few milliseconds too long, you get a glitch.

And if yes, how can I detect this if I record for 30 mins for example? There is a blank sound or something similar? Or I need to listen fully and detect by myself?

Unfortunately, I don't know of any way of detecting buffer overflow automatically.

It's not blank sound (silence). Just as an analogy, if we record ABCDEFG and we get buffer overflow, we could get ACEFG.... There's something missing, but no gap or silence.

When you play back (or monitor) there is a playback buffer that works the opposite way... It gets filled with in quick-burst and the audio data streams-out smoothly to the DAC. With playback, the danger is buffer underflow. With buffer underflow, there will be little gaps-silence (or with video the video can freeze for a moment). i.e. AB...C...D...EF...G.

My conclusion: Use MME (in Audacity) instead of WASAPI if you want the "best quality", is it true?

In the real world, most quality issues are on the analog-side.* All of those protocols are usually better than human hearing. (Of course, that assumes no "glitches" or defects/problems.)

WASAPI has an "Exclusive Mode" which in theory can give you "better quality" because it doesn't allow resampling or the mixing of sounds. Picky-obsessive people who want "bit perfect" audio, use WASAPI exclusive mode or ASIO (a non-Microsoft standard that Audacity doesn't support). But since it's less flexible, exclusive mode is trickier to set-up

I'd start with WASAPI, which is the "latest and greatest", and then try the others if there are problems. Here is some information about the various protocols and their history.




* You can degrade sound quality digitally by using a low-resolution format (like 8-bit/8kHz "telephone quality") or by using highly-compressed lossy compression (like low-quality low-bitrate MP3).

Thank your for your answers and for your links.

Gale Andrews wrote:If you are recording with "Software Playthrough" on, the buffer is at a fixed setting depending on the host choice, and changing "Audio to buffer" will have no effect.

This option is off.

Gale Andrews wrote:As it says in the 2.1.3 Release Notes, "Audio to buffer" cannot be used to adjust recording latency using WASAPI host.

Is it a bug in Audacity? (I understand your answer as "this is not a bug")

Gale Andrews wrote:It is impossible to generalise that MME gives better quality than WASAPI. It depends what you are recording and what audio devices you are using and what drivers those devices have. You gave us no information about that. Older devices may quite conceivably work better with MME or Windows DirectSound but on Windows Vista and later those two hosts are still emulated on top of WASAPI, and so go through WASAPI.

Can you (or other people), if it is possible, give me example(s) how the quality can be altered between MME and WASAPI? As quality, for me it is the "bit perfect" that @DVDdoug said, I think. Please tell me if the definition of the quality is not the same for you, because maybe I am thinking bad for its definition.

Kdmeizk wrote:

Gale Andrews wrote:As it says in the 2.1.3 Release Notes, "Audio to buffer" cannot be used to adjust recording latency using WASAPI host.

Is it a bug in Audacity?

I think so, certainly so for physical inputs.

Kdmeizk wrote:

Gale Andrews wrote:It is impossible to generalise that MME gives better quality than WASAPI. It depends what you are recording and what audio devices you are using and what drivers those devices have. You gave us no information about that. Older devices may quite conceivably work better with MME or Windows DirectSound but on Windows Vista and later those two hosts are still emulated on top of WASAPI, and so go through WASAPI.

Can you (or other people), if it is possible, give me example(s) how the quality can be altered between MME and WASAPI? As quality, for me it is the "bit perfect" that @DVDdoug said, I think. Please tell me if the definition of the quality is not the same for you, because maybe I am thinking bad for its definition.

Are you willing to say what it is you are actually recording, with what device (make and model number)?

There is some information here http://wiki.audacityteam.org/wiki/Windo ... mple_rates and further copious information dotted around in Forum topics written by me and others. You have to use WASAPI host in exclusive mode to get even "close" to "bit perfection".

To cut a long story short, "bit perfection" is impossible in Audacity if you are recording something and don't even accept upconversion from one bit depth to another (which should typically be lossless). This is because Audacity captures sound in 32-bit float and you don't have a 32-bit float recording device - almost no-one has.

If you are importing audio, and just cut audio out without changing the sample values, "bit perfection" is possible. If you want to apply filters that change sample values, bit perfection is impossible unless you have a 32-bit audio file that was never upconverted from a lower bit depth and then export it as 32-bit float WAV. If you try to do it with less than a 32-bit audio file and with no bit depth conversion, then you will add harmonic distortion as the price of bit perfection .

So, for practical puposes, use some other tool than Audacity if bit perfection matters to you above all else, regardless how the music sounds.


Gale

Well, maybe these points will help you:
- I am focusing on 48000 Hz, 16 bits;
- sample rate and bit depth are the same for source and recording (in Audacity so), also my sound card can recording with the same sample rate and bit depth and it is setted to these values;
- the recording is made from my sound card (Realtek) with "stereo mix" I think in English it is this (I record the sound the computer listening).

I wanted to know more general information before specifying.

Kdmeizk wrote:Well, maybe these points will help you:
- I am focusing on 48000 Hz, 16 bits;
- sample rate and bit depth are the same for source and recording (in Audacity so), also my sound card can recording with the same sample rate and bit depth and it is setted to these values;
- the recording is made from my sound card (Realtek) with "stereo mix" I think in English it is this (I record the sound the computer listening).

I wanted to know more general information before specifying.

Please see the information already provided. Recording in "bit perfection" is impossible in Audacity if you don't accept upconversion of bit depth. Only you can make this decision.

And with Realtek stereo mix - why bother with "bit perfection" when stereo mix already has lossy conversions from digital to analogue (to play it) and back to digital (for Audacity to capture it)? At least use Windows WASAPI (loopback), which is entirely digital.

Please note recording from the internet may require copyright holders' permission. We assume you have already sought such permission where necessary.


Gale

Gale Andrews wrote:Please see the information already provided. Recording in "bit perfection" is impossible in Audacity if you don't accept upconversion of bit depth. Only you can make this decision.

I assume the source file is "perfect". If I record with the same bit depth and sample rate, it is not a "bit perfect"? In this case, even 32 bit float is not "bit perfect" so?

Gale Andrews wrote:And with Realtek stereo mix - why bother with "bit perfection" when stereo mix already has lossy conversions from digital to analogue (to play it) and back to digital (for Audacity to capture it)? At least use Windows WASAPI (loopback), which is entirely digital.

I did not know this. I discovered "stereo mix" when I made tests to record the sound that the computer played, I was with MME in Audacity and I had no problems so I never searched more information than this, until this day.


So at this point, WASAPI is a better choice? Even if "Audio to buffer" is impossible to change (for now at least)?