The issue becomes really serious when playing 96 audio files simultaneously. As in: game audio or multitracking DAW (where 24 or more would be recording at the same time, not merely playing back). Every cycle counts there, any cycle not moving audio is a wasted cycle. Indeed, turns out (surprised me when I moved into this field), audio of any paralellism is the hardest Hard Real Time process in a computer audio system, or a game console, or pro audio mixing desks and synth racks. The human ear is the most time critical of our senses; you can drop a video frame and harly anyone notices, but everyone bitches about a dropped audio frame.

ps: this stuff is also achieved in iOS devices. Mind-blowing as that may seem.

pps: just playing audio files is not, in general, latency sensitive, so larger buffers can mask more egregious cycle wasting in the setup and other overhead. Playing sound effect files (gunshots, squealing tires, etc) is however latency sensitive, and there can be many at the same time, so there we shoot for smaller buffers and pay more attention to overhead reduction. In both cases, however, we never start outputting from a buffer that is not filled. Cacheing issues mostly, and also scheduling. Usually that is shared memory, even core to core dual cache shared, with the audio handled in its own subsystem, so there are some very subtle issues at the extremes we work in.

(I'll leave the Monster cable manutroversy out of it here:)