latency issues

[jeremygray]

Lets say s is a Stream() that has exactly 2.000s worth of data to be played (e.g., 96000 samples at 48000Hz). If I time the duration from just prior to s.start() to right after s.is_active() goes false, I usually get an elapsed time of 2.000 to 2.003 s -- which is great.

However, the very first time I run a script like this, it will typically take ~2.52s. If I run it again right away it will be ~2.0s. I can also get a similar ~0.5s longer apparent duration if I play sound s, time.sleep(60), and then start a second 2.000s sound. Here again the apparent duration of the second one will be 0.5s longer than if I only time.sleep(20). In all cases, the sound seems to be the same sound (the pitch would change if samples were stretched out over 2.5s instead of 2.0s).

I am assuming that the extra 0.5s is all just latency to start, i.e., silence prior to the onset / production of any sound, but am not completely certain.

So it seems like maybe portaudio or the hardware soundcard has a "wake up" time of 0.5s, and falls asleep if there's no sound-card (?) activity for about a minute.

Maybe this issue is out of scope for pyscoundcard, but it seems like it might be having a big effect on the achievable latency. People will at least want to know about it. Maybe something like a "stay awake" minimal sound could be sent to the sound card (e.g., a couple samples that are effectively zero in volume).

[bastibe]

This is a very common issue with laptop sound cards, particularly on OS X. Apparently, OS X shuts down the sound hardware completely if no sound is playing. In this case, it can take some time for the sound card to wake up until it is responsive.

You can actually see this in OS X itself, too. If you haven't played a sound in a while and start playing one from the Finder, the first time will start with a short delay. After that, it will play sounds without delay. Thus, it is probably an issue with OS X or CoreAudio, and out of reach for portaudio or pysoundcard.

I don't know whether similar behavior exists on other OSes or hardware, but I certainly have never seen it anywhere else yet.

[jeremygray]

Interesting, good to know! That's my situation exactly.

[jeremygray]

I can confirm that playing a very short, effectively silent sound once every 20 seconds in a loop within a separate python process completely fixes this, while being undetectable by ear.

[mgeier]

That's good to know!

Doesn't it work with an actually silent sound (all zeros) instead of an effectively silent one?

Anyway, If you really care about exact timing, you should use a stream which is always running and find out in the callback function if something has to be played back or not.
To achieve a constant latency (with little jitter), you can use the method Stream.time() to get the time when your actual event occurs and use this time value in the callback to determine the correct time for starting the playback (relative to the current block beginning).
Alternatively, you can also always play immediately at the block beginnings, which reduces latency but increases jitter. If the rhythmic succession of events doesn't matter, the latter should suffice.