Everything to settle before anyone plays a note — line-check order, cue mixes, sample rate, file naming, headroom, backups — plus the five things that ruin sessions and have nothing at all to do with audio.
Sessions rarely fail because of a technical fault. They fail because something that should have been decided in advance got decided in the middle, with a musician sitting in a room waiting, while everyone's attention moved from the music to the equipment.
This is a checklist for the hour before anyone arrives, and for the ten minutes after they do.
Sample rate and bit depth are close to unchangeable once recording has started, so they get decided before the session file is created.
Bit depth: 24-bit. There is no argument here for recording work. It gives you enormous headroom to work with and removes any need to record hot, which is the point of the headroom section below.
Sample rate: 44.1 or 48 kHz for almost everything. Use 48 kHz if the material will ever meet video, since that is the standard there and conversion later is an avoidable annoyance. Higher rates are a real choice with real costs — more storage, more processing, and benefits that are debated rather than obvious — and Course 8.2 covers the reasoning. What matters here is that the decision is made now.
Match the rate to whatever else the project involves. If stems are arriving from elsewhere, or the mix is going to a specific destination, adopt that rate rather than converting later.
This sounds like bureaucracy until the first time someone asks for the third take of the second verse from a session six months old.
A convention that works: project, then source, then take. Song-Vocal-03. Whatever you choose, the requirements are that it sorts sensibly, that it survives being emailed to someone else, and that it contains no characters that break on another operating system — no slashes, no colons, and ideally no spaces.
Name tracks in the session before recording, not after. A session full of Audio 1 through Audio 14 is a session that will be reconstructed by listening to each one.
Aim for peaks around −12 to −18 dBFS, and average levels well below that.
The instinct to record as loud as possible without clipping is inherited from tape and from 16-bit, and it does not apply. At 24-bit the noise floor is so far down that recording 18 dB quieter costs you nothing audible, while giving you room for the take that turns out louder than the rehearsal, for the shout at the end of the chorus, and for every plugin downstream that expects a sensible input level.
Set it during the line check, with the musician playing at the loudest they will actually play, not at the level they demonstrate when asked to play something.
Check every signal path from the source end, one at a time, in a fixed order. The order matters because it means a fault is found at the first point where it could exist rather than after everything downstream has been suspected.
Time this once on your own setup. Knowing it takes eleven minutes rather than 'a few' is what lets you tell a musician honestly when to arrive, which is worth more than it sounds.
A recording exists in one place until you deliberately make it exist in two, and the moment of maximum risk is the session itself — a full drive, a crash, an accidental overwrite between takes.
A performer hearing themselves late will play badly and often will not be able to say why. It is worth resolving before anyone puts headphones on.
Latency is the delay between sound entering the interface and returning to the headphones, and it comes almost entirely from the buffer size — the amount of audio the computer processes at a time. A large buffer is efficient and slow; a small buffer is responsive and demands more of the computer.
The working practice is to use a small buffer while recording and a large one while mixing. Recording is when latency matters and processing load is usually light. Mixing is when the plugin count is high and latency is irrelevant, because nobody is performing.
Better still, use direct monitoring if the interface offers it: the input signal is routed straight back to the headphones in hardware, before it reaches the computer at all, so the delay is effectively zero regardless of buffer size. The cost is that the performer hears the dry signal without any plugins, which for tracking is usually fine and occasionally a problem — a vocalist who needs reverb to perform well needs it from somewhere, and that means either the interface's own effects or accepting some latency.
Whichever route, establish it during the line check with the performer playing. Asking someone mid-session whether the headphones feel delayed rarely gets a useful answer; watching whether they can play in time gets one immediately.
Every one of these has ended more sessions than equipment failure.
Phones. Not just the ringing — a phone left in the recording room will interfere audibly with unbalanced equipment, and more importantly a musician checking messages between takes is a musician who has left the session. Collect them or exile them, and say so in advance so it does not read as rudeness.
Time pressure that nobody stated. If the drummer has to leave at four and this is discovered at half past three, the last hour is wasted. Ask everyone when they need to leave, before starting, and plan the order of work backwards from the earliest departure.
Nobody deciding what a good take is. Without an agreed sense of what you are trying to get, a session can record fourteen takes of the same part and end with no basis for choosing. Decide before recording who makes that call — usually the artist, sometimes the producer, occasionally you — and say it out loud.
Temperature, hunger and fatigue. Performance quality falls steeply after a few hours, and the takes recorded late are usually worse than the ones recorded early, no matter how much better the setup has become by then. Break before people need it. A hot, airless room is worse for a performance than most technical problems, and in much of India an unventilated room with the fan switched off for noise becomes unworkable within an hour — plan for that explicitly, cool the room hard before the session and take breaks with the fan back on.
The engineer performing. Long silences while you fix something, visible frustration, running commentary about equipment. A musician sitting in a live room can see all of it through the glass and reads it as being about them. Talk to people between takes, keep the room moving, and fix things quietly.
A large proportion of home-studio sessions are not bands. They are voiceovers, podcast guests, someone recording their first demo, a student. Everything above applies, and two things change.
They do not know what is normal. A musician who has recorded before understands that the first ten minutes are setup, that takes get repeated, and that silence from the control room is not judgement. Someone who has not will read all of it as things going wrong. Say what you are doing and roughly how long it will take, and the whole session relaxes.
They will be far more self-conscious about their own sound. Hearing your own voice in headphones for the first time is genuinely unsettling, and the usual response is to change how you speak — quieter, more careful, less like yourself. If someone is stiffening up, try lowering their own level in the cue mix rather than raising it, or let them work without headphones entirely if the material allows. The best take is often the one recorded before they had time to start listening to themselves.
Neither is a technical problem, and both do more damage to a recording than most technical problems would.
Something will, and how it is handled decides whether the session survives it.
Have a fallback for every critical path. A spare cable within arm's reach, a second microphone that could do the job, a known-good pair of headphones. Not stored somewhere — physically present in the room. The point is not that faults are likely; it is that a two-minute fix and a twenty-minute hunt feel completely different to everyone waiting.
Say what is happening. Silence while you diagnose is the worst option. A sentence — this channel has dropped out, give me two minutes — keeps the room calm and stops people inventing worse explanations.
Do not debug at the desk while people wait, if you can avoid it. If the fault will take real time, give everyone a break and send them out of the room. Working under an audience makes diagnosis slower and mistakes more likely, and it converts a technical delay into a social one.
Change one thing at a time. The temptation under pressure is to swap the cable, the mic and the channel simultaneously. It usually works and it teaches you nothing, so the same fault returns next week. The line-check order from earlier is also the debugging order: work from the source end, one step at a time.
Know when to move on. If a channel cannot be fixed quickly, record without it and come back. A session that stops entirely while one problem is solved often does not restart, and the takes you did not get are a bigger loss than the channel you did not have.
The pattern in all of this is a single principle. Every decision made before the first take costs a minute; every one postponed until the middle costs an hour and some of the session's momentum, which is the part you cannot recover afterwards.
Every decision you make before the first take costs a minute. Every one you postpone until after it costs an hour, and some of them cost the session.
Students pay for getting unstuck: ask a concept question, routing issue, DAW confusion, or mix decision tied to this lesson.
Free readers can learn from the public Q&A archive. Paid students can ask their own lesson-specific questions and get mentor replies.