Quick answer: tone() emits a square wave at the frequency you ask for, with an optional duration, and it is documented as nonblocking. Its real constraints are that only one tone plays at a time and that it shares timer hardware with PWM on some pins, so plan around those two facts before transcribing melodies.
What the function guarantees
The official Arduino tone() reference states that the function generates a square wave at the requested frequency with an optional duration, and that it is nonblocking. Nonblocking matters: calling tone() does not stall your sketch, so timing, input reading and other work continue. It also means you own the sequencing, because the function starts a tone and your code decides what happens next.
The same reference documents two limits worth internalizing. Only one tone plays at a time, and there are PWM interactions, including interference on classic AVR pin 3 or 11 outside the Mega. Check board and core applicability for your hardware rather than assuming it.
Behavior at a glance
| Property | Documented behavior | Planning implication |
|---|---|---|
| Waveform | Square wave | Buzzer-like timbre, not sampled audio |
| Frequency | Set by the requested value | Choose from your own note table |
| Duration | Optional argument | Stop a tone implicitly or explicitly |
| Blocking | Nonblocking | Sequence the timing yourself |
| Simultaneous tones | One at a time | No polyphony |
| PWM interaction | Pin 3 or 11 on classic AVR outside Mega | Avoid conflicting PWM on those pins |
For a different audio approach, see the DFPlayer Mini playback reference and the USB DAC guide.
Turning sheet music into a data table
- List the distinct pitches you need. A melody is a sequence of notes, so start with the set of frequencies you actually use rather than a giant table.
- Pair each note with a duration. Store pitch and length as two parallel values so the player knows when to advance.
- Keep the data in program memory. Large constant patterns are conventionally held in flash (PROGMEM-style) rather than RAM; treat that as a planning convention, not a guarantee for every board.
- Drive the sequence nonblockingly. Because tone() itself is nonblocking, track elapsed time in your loop and call the next note when the prior duration expires.
- Avoid the PWM-conflicting pins the reference calls out, unless you have checked your specific board and core.
- Use appropriate output hardware. A speaker or buzzer is not automatically a safe GPIO load; follow documented output drive rather than assuming the pin can supply it.
Reader questions
Can I play more than one note at once?
No. The reference documents one tone at a time, so anything chord-like needs a different approach.
Why does a PWM output misbehave while a tone plays?
Because tone() uses timer resources, and the reference specifically notes PWM interference on classic AVR pin 3 or 11 outside the Mega. Check whether those pins are involved in your design.
Is tone() blocking?
No. It is documented as nonblocking, which is convenient but also means your sketch must manage note timing.
Can I connect an eight-ohm speaker straight to a pin?
Do not assume so. A speaker is not automatically a safe GPIO load; use documented output hardware and conservative volume, and make no claim of polyphony or piano-like fidelity.
Documentation
Note: no code execution, board testing or musical reproduction was performed. Speaker load, board and core portability, and compatibility with any particular melody are not verified here. Treat a speaker or buzzer as an output load to be driven per its documentation, not as something a pin can supply directly.
