On 04/01/21 7:01 am, tim Rowledge wrote:
> It depends upon the details of the OS sound handling; if the OS takes
> a copy of the squeak buffer then in a sense said squeak buffer is now
> completely empty and ready to be filled completely. But what if the
> next attempt to pass a buffer finds that the OS cannot accept any
> more samples just yet? How complicated can we make this?

Latency could be introduced in any layer - driver, kernel, library, app.

* aplay plays local files well that rules out any latency issues in 
lib/kernel/driver layers.
* PulseAudio introduces another buffering layer with its audio server 
app. pactl should reveal this.
* Squeak also uses its own buffers. As an app, it could be subject to 
fair-share scheduling. As an interpreter, Squeak would be CPU intensive 
workload. If there are other CPU intensive loads, then its scheduling 
latency may impact audio play.

In addition to pactl, I would also have vmstat running in a separate 
terminal to reveal CPU/RAM/IO spikes.
  $ vmstat 5

HTH .. Subbu