AudioStreamPlayer3D.get_playback_position() always returns 0 right after using seek or play(from_position)

[MajorMcDoom]

Tested versions

Reproducible in 4.3.stable and 4.4.dev5

System information

Godot v4.4.dev5 - Windows 10.0.22631 - Multi-window, 1 monitor - OpenGL 3 (Compatibility) - NVIDIA GeForce GTX 1660 SUPER (NVIDIA; 32.0.15.6603) - Intel(R) Core(TM) i7-10700F CPU @ 2.90GHz (16 threads)

Issue description

AudioStreamPlayer3D.get_playback_position() returns 0 right after using seek(...) or play(...) with a non-zero argument. The actual seek operation works, and get_playback_position will eventually return the correct time, but the expected behaviour is for it to report the correct number immediately.

The non-spatialized version of this node, AudioStreamPlayer, does not have the same issue (get_playback_position always returns the correct value).

Steps to reproduce

• Run the test scene in the attached project.
• Press the Seek button.
• Observe the console.

Minimal reproduction project (MRP)

bug-report.zip

[Mickeon]

The 2D version of this node, AudioStreamPlayer, does not have the same issue (get_playback_position always returns the correct value).

I was mislead by this statement. The 2D version would be AudioStreamPlayer2D. AudioStreamPlayer has no position in space and indeed does not have this problem. There are some differences between the 2D and 3D versions in the code which are obvious oversights and are fixed by #99734 (as of writing this), but they do not fix this issue specifically.

[Mickeon]

Upon a second look, this is (once again) an issue involving AudioStreamPlayer2D and AudioStreamPlayer3D not playing right away. Rather, they always wait for the next internal frame. On seek, the audio stops and plays again. There's no AudioStreamPlayback yet, hence nothing is playing, hence it returns 0.

This is actually documented:

Queues the audio to play on the next physics frame, from the given position [param from_position], in seconds.

But one may consider this a bug, still.

[MajorMcDoom]

The 2D version of this node, AudioStreamPlayer, does not have the same issue (get_playback_position always returns the correct value).

I was mislead by this statement. The 2D version would be AudioStreamPlayer2D. AudioStreamPlayer has no position in space and indeed does not have this problem. There are some differences between the 2D and 3D versions in the code which are obvious oversights and are fixed by #99734 (as of writing this), but they do not fix this issue specifically.

That is my bad. I should have said "non-spatialized". I have corrected this.

[MajorMcDoom]

Upon a second look, this is (once again) an issue involving AudioStreamPlayer2D and AudioStreamPlayer3D not playing right away. Rather, they always wait for the next internal frame. On seek, the audio stops and plays again. There's no AudioStreamPlayback yet, hence nothing is playing, hence it returns 0.

This is actually documented:

Queues the audio to play on the next physics frame, from the given position [param from_position], in seconds.

But one may consider this a bug, still.

I was aware of this caveat. However I was under the impression that although no action is taken until the next frame (as in the audio itself does not immediately change), the values reported would still accurately reflect the desired, imminent state.

But ultimately, it is the inconsistency between AudioStreamPlayer3D and AudioStreamPlayer that makes more of a case for this being treated as a "bug", because the same script that works for one may not work for the other, and vice versa.