AudioStreamInteractive can't loop clips

[Crafty-Jumper]

Tested versions

As far as I'm aware,

• v4.4.1.stable
• v4.4.stable

System information

Godot v4.4.1.stable - Windows 11 (build 26100) - Multi-window, 1 monitor - Vulkan (Forward+) - integrated AMD Radeon(TM) Graphics (Advanced Micro Devices, Inc.; 32.0.11016.15002) - AMD Ryzen 5 7520U with Radeon Graphics (8 threads)

Issue description

It's as simple as this. setting an AudioStreamInteractive clip to auto-advance to itself doesn't work.

Steps to reproduce

1. new AudioStreamPlayer node
2. set stream to AudioStreamInteractive
3. add a clip the the stream
4. set auto-advance to enabled and set the next clip to itself
5. play the audio

Minimal reproduction project (MRP)

project.zip

[alejandro-alzate]

I found a beautiful and strange workaround.

1. Make a duplicate of the sound you want to loop.
2. make them point to each other.

Somehow both play at the same time according with the inspector which screams a whole new bug on its own

[Jojo-1000]

I looked at the code and there are two places that handle the auto advance. Both of them explicitly check and exclude the case that the next clip has the same index as the currently active one. If I just remove that code, the whole playback breaks, so there seems to be a reason for this.

Would it be a viable fix to disable this selection (so that it would be empty with just one clip) and instead enable loop on the audio stream itself (if you open up the import options of the file it has a loop mode)?

[alejandro-alzate]

Yeah what's up with that, why we cant poke at fields of the streams?
What's the technical reason for that?
It got me curious.

What is the point of "transition on next bar/beat" if the bpm can't be set?

and I have an idea, currently the finished signal is dead.
what about reusing it for when a transition is about to happen?

[alejandro-alzate]

I looked at the code and there are two places that handle the auto advance. Both of them explicitly check and exclude the case that the next clip has the same index as the currently active one. If I just remove that code, the whole playback breaks, so there seems to be a reason for this.

Regarding this insight, if a check is explicitly made on this scenario what's stopping us of putting the equivalent of stop() then play() Back to Back or just seek(0) there?

Maybe because I'm incompetent with C-derived languages and I'm probably grasping how the AudioStreamInteractive works completely wrong but surely there's a way isn't it?

[Jojo-1000]

Yeah what's up with that, why we cant poke at fields of the streams?
What's the technical reason for that?
It got me curious.

You can turn on looping and maybe other settings as well if you click on the audio file and go to the import settings (hidden behind the node tree for me).

Regarding this insight, if a check is explicitly made on this scenario what's stopping us of putting the equivalent of stop() then play() Back to Back or just seek(0) there?

It would certainly be possible to fix this, but there is quite complex transition logic that relies on a from-state and a to-state for fading and stuff. The assumption is that these states are separate, which breaks in this scenario.

[alejandro-alzate]

You can turn on looping and maybe other settings as well if you click on the audio file and go to the import settings (hidden behind the node tree for me).

I for the love of god didn't found where to look

[Jojo-1000]

@alejandro-alzate I don't know if you found it or not, this is where I could change the loop mode:

If you change this to forward and reimport, it will loop without the auto advance.

[alejandro-alzate]

@Jojo-1000
I'm currently using ogg.
I'm forced to use WAV?