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 [u]Glitch Free[/u]. 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 _under_flow. 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. [u]Here[/u] 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).