Add AudioStreamPlayerInternal to unify stream players #87061

KoBeWi · 2024-01-10T21:01:47Z

We have 3 AudioStreamPlayer classes and they share a lot of code. Code duplication, especially this big, is bad and that doesn't need explaining. Every fix or common feature has to be implemented 3 times and there is risk of code differences that result in bugs.

This PR tries to unify the code under a single class - AudioStreamPlayerInternal. It's an internal class used by the 3 audio players (not by inheritance). I delegated all common code and fields to the new class. The best indicator how big was the code duplication is that this PR has more deleted lines despite I added a whole new class. I also cleaned up some includes.

I tried to avoid introducing changes, but there are small differences from the original code, mostly in the order of some lines (some things were ordered differently in different players and common methods will obviously unify that). Probably needs testing to check whether all features are still working and there is no change in behavior. I did some basic tests and the audio still plays at least.

In the meantime I also came up with an alternate approach of taking advantage of C++ multiple inheritance. Maybe I'll try that too, as it should save some more code and possibly make it more readable.

KoBeWi · 2024-01-10T21:03:15Z

scene/2d/audio_stream_player_2d.cpp

 			}
+			internal.ensure_playback_limit();


The playback limit is applied each frame, unlike in AudioStreamPlayer, which does it only on play(). Maybe other players could do that too?

The playback limit is applied each frame, unlike in AudioStreamPlayer, which does it only on play(). Maybe other players could do that too?

Sounds and looks reasonable to me. Then ensure_playback_limit can be removed altogether and its content moved into play_basic

KoBeWi · 2024-01-10T21:04:17Z

scene/audio/audio_stream_player.cpp

-	} else {
-		stop();
-	}
+	internal.set_playing(p_enable);
 }

 bool AudioStreamPlayer::_is_active() const {


This method code was the same as is_playing(). I unified it to do active.is_set() as other players, idk if it makes difference.

This method code was the same as is_playing(). I unified it to do active.is_set() as other players, idk if it makes difference.

Hm… for AudioStreamPlayer, the meaning changes from "AudioServer has my playback registered and setup, and started playing" to "I started being processed and the AudioServer is about to start setting up my playback".

But no idea if this has any tangible repercussions. _is_active is a Node thing afaik

Not sure if relevant, but does animation use this for syncing the start? Audio already starts earlier than other things. For reference: #82698 (comment)

scene/3d/audio_stream_player_3d.cpp

Mickeon · 2024-01-10T21:08:41Z

In the meantime I also came up with an alternate approach of taking advantage of C++ multiple inheritance. Maybe I'll try that too, as it should save some more code and possibly make it more readable.

I'm very interested. Readability seems to be the must. But, is something like the suggestion ever used across the rest of the codebase?

Whatever path is taken to unite the AudioStreamPlayers, it would be nice in the future to do the same for other classes with a lot of duplicated code.

ellenhp · 2024-01-10T21:23:31Z

An important discussion point is whether this may interfere with people creating custom streams with gdextension. I think the answer is no because they can just inherit audiostream and continue duplicating all the code we're consolidating here. But that's a use case I want us to continue supporting so I want to bring it up :)

Mickeon · 2024-01-10T21:31:28Z

Compatibility is retained by doing this. From the outsider's perspective nothing should change.

KoBeWi · 2024-01-10T21:37:10Z

But, is something like the suggestion ever used across the rest of the codebase?

No, AFAIK every class is single inheritance.

I tried that approach and seems like you can't bind methods from another class (in that case AudioStreamPlayerInternal would be the secondary parent class), which makes it useless. Maybe there is a way to untangle the inheritance, but it's not that easy, so meh. The solution in this PR is better than what we have anyway.

EDIT:
Seems like there is a crash in CI, but I don't get what is it about.

ellenhp · 2024-01-10T21:39:31Z

Compatibility is retained by doing this. From the outsider's perspective nothing should change.

Yeah makes sense, I'm just trying to be thorough. I also think we should come up with a better name because we have a couple audio streams that won't end up subclassing this new internal class because they're dynamic (microphone, generator, probably others).

I misunderstood this PR actually, oops.

Mickeon · 2024-01-10T21:42:26Z

It could be called something like "Core", since it's the center of all AudioStreamPlayers. I had it for a bit and it's the only thing that comes to mind.

KoBeWi · 2024-01-10T21:42:55Z

I also think we should come up with a better name because we have a couple audio streams that won't end up subclassing this new internal class

The new class is for audio stream players (it's AudioStreamPlayerInternal), not audio streams. I think the name is fine.

ellenhp · 2024-01-10T21:48:02Z

Yeah sorry, neither of my comments make any sense for this. I got a covid vaccine about 36 hours ago and I'm still in the living dead phase of recovery. Didn't help that I hadn't looked at the code yet. I do want to refactor streams at some point too but there's a lot less we can do there without breaking stuff. As you noted, you can't create a new player in GDExtension yet so we really don't have to worry about breaking compat, and I'm not even aware of any custom modules that implement their own players without going through an entirely different middleware.

MJacred

The rest should be fine, I'd say. Some processing order was changed, e.g. in _notification, but should make no difference (I think).

scene/3d/audio_stream_player_3d.cpp

scene/audio/audio_stream_player_internal.cpp

scene/2d/audio_stream_player_2d.cpp

scene/3d/audio_stream_player_3d.cpp

MJacred · 2024-01-15T14:31:37Z

scene/2d/audio_stream_player_2d.cpp

 			}
+			internal.ensure_playback_limit();


The playback limit is applied each frame, unlike in AudioStreamPlayer, which does it only on play(). Maybe other players could do that too?

Sounds and looks reasonable to me. Then ensure_playback_limit can be removed altogether and its content moved into play_basic

MJacred · 2024-01-15T15:05:42Z

scene/audio/audio_stream_player.cpp

-	} else {
-		stop();
-	}
+	internal.set_playing(p_enable);
 }

 bool AudioStreamPlayer::_is_active() const {


This method code was the same as is_playing(). I unified it to do active.is_set() as other players, idk if it makes difference.

Hm… for AudioStreamPlayer, the meaning changes from "AudioServer has my playback registered and setup, and started playing" to "I started being processed and the AudioServer is about to start setting up my playback".

But no idea if this has any tangible repercussions. _is_active is a Node thing afaik

scene/audio/audio_stream_player_internal.cpp

scene/2d/audio_stream_player_2d.h

scene/3d/audio_stream_player_3d.cpp

KoBeWi · 2024-01-16T13:59:40Z

Rebased and updated. I had to change the AudioStreamPlayerInternal to Object, to handle the newly added parameter_list_changed signal. I also fixed the null issue from #86473.

reduz

Looks good, I was hopeful it would save more code, but I guess its still a lot less error prone and easier to maintain. Great work!

akien-mga · 2024-01-17T07:25:30Z

Failing test:

./tests/core/object/test_class_db.h:833:
TEST SUITE: [ClassDB]
TEST CASE:  [ClassDB] Add exposed classes, builtin types, and global enums
  [ClassDB] Validate exposed classes

./tests/core/object/test_class_db.h:376: ERROR: CHECK_FALSE( (p_arg.name.is_empty() || p_arg.name.begins_with("_unnamed_arg")) ) is NOT correct!
  values: CHECK_FALSE( true )
  logged: Unnamed argument in position 0 of method 'AudioStreamPlayer2D.set_pitch_scale'.

scene/audio/audio_stream_player_internal.h

YuriSizov

Gave it a quick look, and it looks good!

akien-mga · 2024-01-18T08:36:32Z

Thanks!

KoBeWi added enhancement topic:audio topic:codestyle labels Jan 10, 2024

KoBeWi added this to the 4.3 milestone Jan 10, 2024

KoBeWi requested review from a team as code owners January 10, 2024 21:01

KoBeWi commented Jan 10, 2024

View reviewed changes

scene/3d/audio_stream_player_3d.cpp Outdated Show resolved Hide resolved

KoBeWi force-pushed the shadow_of_the_former_self branch from 65ee045 to 891598b Compare January 10, 2024 21:12

KoBeWi force-pushed the shadow_of_the_former_self branch from 891598b to edfcf81 Compare January 10, 2024 22:00

KoBeWi mentioned this pull request Jan 13, 2024

Implement audio stream playback parameters. #86473

Merged

MJacred suggested changes Jan 15, 2024

View reviewed changes

KoBeWi force-pushed the shadow_of_the_former_self branch from edfcf81 to cc7703c Compare January 16, 2024 13:59

reduz approved these changes Jan 16, 2024

View reviewed changes

Add AudioStreamPlayerInternal to unify stream players

0c7db3c

KoBeWi force-pushed the shadow_of_the_former_self branch from cc7703c to 0c7db3c Compare January 17, 2024 12:12

YuriSizov reviewed Jan 17, 2024

View reviewed changes

scene/audio/audio_stream_player_internal.h Show resolved Hide resolved

YuriSizov approved these changes Jan 17, 2024

View reviewed changes

akien-mga merged commit 8f9c815 into godotengine:master Jan 18, 2024
15 checks passed

KoBeWi deleted the shadow_of_the_former_self branch January 18, 2024 09:54

KoBeWi mentioned this pull request Jan 22, 2024

Synchronize Audio Playback with BPM (Bar/Beats) godotengine/godot-proposals#8937

Open

aaronfranke mentioned this pull request Jan 30, 2024

AudioStreamPlayer3D autoplay does not work after AudioStreamPlayerInternal refactor #87730

Closed

EnlightenedOne mentioned this pull request Feb 1, 2024

AudioStreamPlayer does not call "finished" signal #87802

Closed

lander-vr mentioned this pull request Mar 13, 2024

Expose AudioStreamPlayerInternal to GDExtension godotengine/godot-proposals#9295

Open

kus04e4ek mentioned this pull request Aug 11, 2024

Setting playing to true and then to false on the same frame results in playing still being true #95385

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add AudioStreamPlayerInternal to unify stream players #87061

Add AudioStreamPlayerInternal to unify stream players #87061

KoBeWi commented Jan 10, 2024

KoBeWi Jan 10, 2024

MJacred Jan 15, 2024 •

edited

Loading

KoBeWi Jan 10, 2024

MJacred Jan 15, 2024 •

edited

Loading

MJacred Jan 15, 2024

Mickeon commented Jan 10, 2024

ellenhp commented Jan 10, 2024

Mickeon commented Jan 10, 2024

KoBeWi commented Jan 10, 2024 •

edited

Loading

ellenhp commented Jan 10, 2024 •

edited

Loading

Mickeon commented Jan 10, 2024 •

edited

Loading

KoBeWi commented Jan 10, 2024

ellenhp commented Jan 10, 2024

MJacred left a comment

MJacred Jan 15, 2024 •

edited

Loading

MJacred Jan 15, 2024 •

edited

Loading

KoBeWi commented Jan 16, 2024

reduz left a comment

akien-mga commented Jan 17, 2024

YuriSizov left a comment

akien-mga commented Jan 18, 2024

Add AudioStreamPlayerInternal to unify stream players #87061

Add AudioStreamPlayerInternal to unify stream players #87061

Conversation

KoBeWi commented Jan 10, 2024

KoBeWi Jan 10, 2024

Choose a reason for hiding this comment

MJacred Jan 15, 2024 • edited Loading

Choose a reason for hiding this comment

KoBeWi Jan 10, 2024

Choose a reason for hiding this comment

MJacred Jan 15, 2024 • edited Loading

Choose a reason for hiding this comment

MJacred Jan 15, 2024

Choose a reason for hiding this comment

Mickeon commented Jan 10, 2024

ellenhp commented Jan 10, 2024

Mickeon commented Jan 10, 2024

KoBeWi commented Jan 10, 2024 • edited Loading

ellenhp commented Jan 10, 2024 • edited Loading

Mickeon commented Jan 10, 2024 • edited Loading

KoBeWi commented Jan 10, 2024

ellenhp commented Jan 10, 2024

MJacred left a comment

Choose a reason for hiding this comment

MJacred Jan 15, 2024 • edited Loading

Choose a reason for hiding this comment

MJacred Jan 15, 2024 • edited Loading

Choose a reason for hiding this comment

KoBeWi commented Jan 16, 2024

reduz left a comment

Choose a reason for hiding this comment

akien-mga commented Jan 17, 2024

YuriSizov left a comment

Choose a reason for hiding this comment

akien-mga commented Jan 18, 2024

MJacred Jan 15, 2024 •

edited

Loading

MJacred Jan 15, 2024 •

edited

Loading

KoBeWi commented Jan 10, 2024 •

edited

Loading

ellenhp commented Jan 10, 2024 •

edited

Loading

Mickeon commented Jan 10, 2024 •

edited

Loading

MJacred Jan 15, 2024 •

edited

Loading

MJacred Jan 15, 2024 •

edited

Loading