I have something fairly short to point out, and because I couldn't find anything about it on the wiki or the manual, I figured I'd share this with everyone. Specially because I also want to know if this is a glitch or not.

al_get_audio_stream_position_secs doesn't actually return the exact playing position of an audio stream. There's a delay. Luckily this delay can be calculated: number_of_buffers * buffer_size_in_samples / song_frequency. If when you call al_get_audio_stream_position_secs, you subtract that value, you'll get the true position.

Partially related, but I also realized that al_get_audio_stream_position_secs only actually updates when all buffers have finished playing their part and need a refill, from what I can tell. Decreasing the number of buffers and/or their size will increase the frequency of the update (and thus, the precision of the position).

Hopefully this can help someone that has timing issues . I kept hitting the beats slightly late on my game, PK Rhythm, and when I tried checking if the position was correct, by creating an audio file that played noise at an exact point, then trying to catch said point's position in slow motion, I came to this conclusion. After implementing the simple delay compensation, the game feels a lot more precise.

Also, it should be worth noticing I asked a friend with a laptop that's the same as mine - but on a Linux OS instead of Windows 7 - to test it, and the delay was the same. Another friend with a more powerful machine, running Windows 7 also had the same delay. So this solution should work every time.

Now I'm now wondering if this is a glitch... Is it too hard to get the actual playing position, without this weird delay compensation + low update frequency that al_get_audio_stream_position_secs has? Surely the mixer or voice must save the current position, so it knows which values to play next...

Anyway, could anyone add a brief notice of this delay on the al_get_audio_stream_position_secs page of the manual?

There are always layers of buffering between the program and the sound card, at least on general purpose computers. The more buffering the less chance of underrun (i.e. not enough data available when the sound card wants it) but the higher the latency.

Without thinking about it too hard, I think you estimated the delay between adding something to an almost-full ALLEGRO_AUDIO_STREAM, and Allegro handing that off to the OS. There would probably be some (lesser) delay before that reaches the sound card.

That doesn't sound like desirable behaviour. It could at least update when a fragment is done playing... I think.

...Oh, just noticed my calculated delay is actually explained on al_create_audio_stream's manual page. Well, good to know I didn't come up with a quick fix, but rather with the real solution. We really need someone to add this info on the manual's al_get_audio_stream_position_secs page, still.