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?