mirrors
/
CC-Tweaked
mirror of https://github.com/SquidDev-CC/CC-Tweaked
1
0
Fork 0
Code Issues Releases Wiki Activity
CC-Tweaked/projects/common/src/main/java/dan200/computercraft/shared/network/client/SpeakerAudioClientMessage.java

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

60 lines
2.2 KiB
Java
Raw Normal View History

License CC:T according to the REUSE specification (#1351) This adds SPDX license headers to all source code files, following the REUSE[1] specification. This does not include any asset files (such as generated JSON files, or textures). While REUSE does support doing so with ".license" files, for now we define these licences using the .reuse/dep5 file. [1]: https://reuse.software/
2023-03-15 21:52:13 +00:00
// SPDX-FileCopyrightText: 2021 The CC: Tweaked Developers
//
// SPDX-License-Identifier: MPL-2.0
Add arbitrary audio support to speakers (#982) Speakers can now play arbitrary PCM audio, sampled at 48kHz and with a resolution of 8 bits. Programs can build up buffers of audio locally, play it using `speaker.playAudio`, where it is encoded to DFPWM, sent across the network, decoded, and played on the client. `speaker.playAudio` may return false when a chunk of audio has been submitted but not yet sent to the client. In this case, the program should wait for a speaker_audio_empty event and try again, repeating until it works. While the API is a little odd, this gives us fantastic flexibility (we can play arbitrary streams of audio) while still being resilient in the presence of server lag (either TPS or on the computer thread). Some other notes: - There is a significant buffer on both the client and server, which means that sound take several seconds to finish after playing has started. One can force it to be stopped playing with the new `speaker.stop` call. - This also adds a `cc.audio.dfpwm` module, which allows encoding and decoding DFPWM1a audio files. - I spent so long writing the documentation for this. Who knows if it'll be helpful!
2021-12-13 22:56:59 +00:00
package dan200.computercraft.shared.network.client;
import dan200.computercraft.shared.network.NetworkMessage;
Add a MessageType for network messages Everything old is new again! CC's network message implementation has gone through several iterations: - Originally network messages were implemented with a single class, which held an packet id/type and and opaque blobs of data (as string/int/byte/NBT arrays), and a big switch statement to decode and process this data. - In 42d3901ee37892e259de26ebb57cf59ce284416e, we split the messages into different classes all inheriting from NetworkMessage - this bit we've stuck with ever since. Each packet had a `getId(): int` method, which returned the discriminator for this packet. - However, getId() was only used when registering the packet, not when sending, and so in ce0685c31f7315d15d3250c6c8605171b33aa99f we removed it, just passing in a constant integer at registration instead. - In 53abe5e56eec6840890770b6ec36a5d009357da7, we made some relatively minor changes to make the code more multi-loader/split-source friendly. However, this meant when we finally came to add Fabric support (8152f19b6efd71b66c3821ad94aacaddb7d26298), we had to re-implement a lot of Forge's network code. In 1.20.4, Forge moves to a system much closer to Fabric's (and indeed, Minecraft's own CustomPacketPayload), and so it makes sense to adapt to that now. As such, we: - Add a new MessageType interface. This is implemented by the loader-specific modules, and holds whatever information is needed to register the packet (e.g. discriminator, reader function). - Each NetworkMessage now has a type(): MessageType<?> function. This is used by the Fabric networking code (and for NeoForge's on 1.20.4) instead of a class lookup. - NetworkMessages now creates/stores these MessageType<T>s (much like we'd do for registries), and provides getters for the clientbound/serverbound messages. Mod initialisers then call these getters to register packets. - For Forge, this is relatively unchanged. For Fabric, we now `FabricPacket`s.
2024-01-03 09:15:38 +00:00
import dan200.computercraft.shared.network.NetworkMessages;
Send entire DFPWM encoder state to the client This ensures the client decoder is in sync with the server. Well, mostly - we don't handle the anti-jerk, but that should correct itself within a few samples. Fixes #1748
2024-03-15 18:25:57 +00:00
import dan200.computercraft.shared.peripheral.speaker.EncodedAudio;
Split CC:T into common and forge projects After several weeks of carefully arranging ribbons, we pull the string and end up with, ... a bit of a messy bow. There were still some things I'd missed. - Split the mod into a common (vanilla-only) project and Forge-specific project. This gives us room to add Fabric support later on. - Split the project into main/client source sets. This is not currently statically checked: we'll do that soon. - Rename block/item/tile entities to use suffixes rather than prefixes.
2022-11-09 23:58:56 +00:00
import dan200.computercraft.shared.peripheral.speaker.SpeakerBlockEntity;
Update to 1.20.5 - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 19:17:43 +00:00
import dan200.computercraft.shared.peripheral.speaker.SpeakerPeripheral;
Track owning entity when sending sounds This allows us to sync the position to the entity immediately, rather than the sound jumping about. Someone has set up rick-rolling pocket computers (<3 to whoever did this), and the lag on them irritates me enough to fix this. Fixes #1074
2022-04-28 18:54:28 +00:00
import dan200.computercraft.shared.peripheral.speaker.SpeakerPosition;
Update to 1.20.5 - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 19:17:43 +00:00
import net.minecraft.core.UUIDUtil;
import net.minecraft.network.RegistryFriendlyByteBuf;
import net.minecraft.network.codec.ByteBufCodecs;
import net.minecraft.network.codec.StreamCodec;
import net.minecraft.network.protocol.common.custom.CustomPacketPayload;
Add arbitrary audio support to speakers (#982) Speakers can now play arbitrary PCM audio, sampled at 48kHz and with a resolution of 8 bits. Programs can build up buffers of audio locally, play it using `speaker.playAudio`, where it is encoded to DFPWM, sent across the network, decoded, and played on the client. `speaker.playAudio` may return false when a chunk of audio has been submitted but not yet sent to the client. In this case, the program should wait for a speaker_audio_empty event and try again, repeating until it works. While the API is a little odd, this gives us fantastic flexibility (we can play arbitrary streams of audio) while still being resilient in the presence of server lag (either TPS or on the computer thread). Some other notes: - There is a significant buffer on both the client and server, which means that sound take several seconds to finish after playing has started. One can force it to be stopped playing with the new `speaker.stop` call. - This also adds a `cc.audio.dfpwm` module, which allows encoding and decoding DFPWM1a audio files. - I spent so long writing the documentation for this. Who knows if it'll be helpful!
2021-12-13 22:56:59 +00:00
import java.util.UUID;
/**
* Starts a sound on the client.
Some improvements to Javadoc publishing - Use <p> everywhere. This is uglier, but also technically more correct. This requires a version bump to cct-javadoc, and will give me a massive headache when merging. - Link against the existing OpenJDK docs.
2022-10-25 18:17:55 +00:00
* <p>
Add arbitrary audio support to speakers (#982) Speakers can now play arbitrary PCM audio, sampled at 48kHz and with a resolution of 8 bits. Programs can build up buffers of audio locally, play it using `speaker.playAudio`, where it is encoded to DFPWM, sent across the network, decoded, and played on the client. `speaker.playAudio` may return false when a chunk of audio has been submitted but not yet sent to the client. In this case, the program should wait for a speaker_audio_empty event and try again, repeating until it works. While the API is a little odd, this gives us fantastic flexibility (we can play arbitrary streams of audio) while still being resilient in the presence of server lag (either TPS or on the computer thread). Some other notes: - There is a significant buffer on both the client and server, which means that sound take several seconds to finish after playing has started. One can force it to be stopped playing with the new `speaker.stop` call. - This also adds a `cc.audio.dfpwm` module, which allows encoding and decoding DFPWM1a audio files. - I spent so long writing the documentation for this. Who knows if it'll be helpful!
2021-12-13 22:56:59 +00:00
* Used by speakers to play sounds.
*
Update to 1.20.5 - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 19:17:43 +00:00
* @param source The {@linkplain SpeakerPeripheral#getSource() id} of the speaker playing audio.
* @param pos The position of the speaker.
* @param content The audio to play.
* @param volume The volume to play the audio at.
Split CC:T into common and forge projects After several weeks of carefully arranging ribbons, we pull the string and end up with, ... a bit of a messy bow. There were still some things I'd missed. - Split the mod into a common (vanilla-only) project and Forge-specific project. This gives us room to add Fabric support later on. - Split the project into main/client source sets. This is not currently statically checked: we'll do that soon. - Rename block/item/tile entities to use suffixes rather than prefixes.
2022-11-09 23:58:56 +00:00
* @see SpeakerBlockEntity
Add arbitrary audio support to speakers (#982) Speakers can now play arbitrary PCM audio, sampled at 48kHz and with a resolution of 8 bits. Programs can build up buffers of audio locally, play it using `speaker.playAudio`, where it is encoded to DFPWM, sent across the network, decoded, and played on the client. `speaker.playAudio` may return false when a chunk of audio has been submitted but not yet sent to the client. In this case, the program should wait for a speaker_audio_empty event and try again, repeating until it works. While the API is a little odd, this gives us fantastic flexibility (we can play arbitrary streams of audio) while still being resilient in the presence of server lag (either TPS or on the computer thread). Some other notes: - There is a significant buffer on both the client and server, which means that sound take several seconds to finish after playing has started. One can force it to be stopped playing with the new `speaker.stop` call. - This also adds a `cc.audio.dfpwm` module, which allows encoding and decoding DFPWM1a audio files. - I spent so long writing the documentation for this. Who knows if it'll be helpful!
2021-12-13 22:56:59 +00:00
*/
Update to 1.20.5 - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 19:17:43 +00:00
public record SpeakerAudioClientMessage(
UUID source,
SpeakerPosition.Message pos,
EncodedAudio content,
float volume
) implements NetworkMessage<ClientNetworkContext> {
public static final StreamCodec<RegistryFriendlyByteBuf, SpeakerAudioClientMessage> STREAM_CODEC = StreamCodec.composite(
UUIDUtil.STREAM_CODEC, SpeakerAudioClientMessage::source,
SpeakerPosition.Message.STREAM_CODEC, SpeakerAudioClientMessage::pos,
EncodedAudio.STREAM_CODEC, SpeakerAudioClientMessage::content,
ByteBufCodecs.FLOAT, SpeakerAudioClientMessage::volume,
SpeakerAudioClientMessage::new
);
Add arbitrary audio support to speakers (#982) Speakers can now play arbitrary PCM audio, sampled at 48kHz and with a resolution of 8 bits. Programs can build up buffers of audio locally, play it using `speaker.playAudio`, where it is encoded to DFPWM, sent across the network, decoded, and played on the client. `speaker.playAudio` may return false when a chunk of audio has been submitted but not yet sent to the client. In this case, the program should wait for a speaker_audio_empty event and try again, repeating until it works. While the API is a little odd, this gives us fantastic flexibility (we can play arbitrary streams of audio) while still being resilient in the presence of server lag (either TPS or on the computer thread). Some other notes: - There is a significant buffer on both the client and server, which means that sound take several seconds to finish after playing has started. One can force it to be stopped playing with the new `speaker.stop` call. - This also adds a `cc.audio.dfpwm` module, which allows encoding and decoding DFPWM1a audio files. - I spent so long writing the documentation for this. Who knows if it'll be helpful!
2021-12-13 22:56:59 +00:00
Send entire DFPWM encoder state to the client This ensures the client decoder is in sync with the server. Well, mostly - we don't handle the anti-jerk, but that should correct itself within a few samples. Fixes #1748
2024-03-15 18:25:57 +00:00
public SpeakerAudioClientMessage(UUID source, SpeakerPosition pos, float volume, EncodedAudio content) {
Update to 1.20.5 - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 19:17:43 +00:00
this(source, pos.asMessage(), content, volume);
Add arbitrary audio support to speakers (#982) Speakers can now play arbitrary PCM audio, sampled at 48kHz and with a resolution of 8 bits. Programs can build up buffers of audio locally, play it using `speaker.playAudio`, where it is encoded to DFPWM, sent across the network, decoded, and played on the client. `speaker.playAudio` may return false when a chunk of audio has been submitted but not yet sent to the client. In this case, the program should wait for a speaker_audio_empty event and try again, repeating until it works. While the API is a little odd, this gives us fantastic flexibility (we can play arbitrary streams of audio) while still being resilient in the presence of server lag (either TPS or on the computer thread). Some other notes: - There is a significant buffer on both the client and server, which means that sound take several seconds to finish after playing has started. One can force it to be stopped playing with the new `speaker.stop` call. - This also adds a `cc.audio.dfpwm` module, which allows encoding and decoding DFPWM1a audio files. - I spent so long writing the documentation for this. Who knows if it'll be helpful!
2021-12-13 22:56:59 +00:00
}
@Override
Make net code more multi-loader friendly NetworkMessage follows vanilla's Packet much more closely now: the handler takes a context argument, which varies between the client and server. - The server handler just returns the ServerPlayer who sent the message. - The client context provides handleXyz(...) methods for each clientbound packet. Our packet subclasses call the appropriate method - the implementation of which contains the actual implementation. Doing this allows us to move a whole bunch of client-specific code into the main client package, dropping several @OnlyIn annotations and generally reducing the risk of accidentally loading client classes on the server. We also abstract out some packet sending and general networking code to make it easier to use in a multi-loader context.
2022-11-06 20:12:32 +00:00
public void handle(ClientNetworkContext context) {
Simplify our networking multi-platform code Historically we used Forge's SimpleChannel methods (and PacketDistributor) to send the packets to the client. However, we don't need to do that - it is sufficient to convert it to a vanilla packet, and send the packet ourselves. Given we need to do this on Fabric, it makes sense to do this on Forge as well. This allows us to unify (and thus simplify) a lot of how packet sending works. At the same time, we also remove the handling of speaker audio during decoding. We originally did this to avoid the additional copy of audio data. However, this doesn't work on 1.20.4 (as packets aren't encoded/decoded on singleplayer), so it makes sense to do this Correctly(TM). This also allows us to get rid of ClientNetworkContext.get(). We do still need to service load this class (as Forge's networking isn't split up in the same way Fabric's is), but we'll be able to drop that in 1.20.4. Finally, we move the record playing code from ClientNetworkContext to ClientPlatformHelper. This means the network context no longer needs to be platform-specific!
2024-01-14 22:52:25 +00:00
context.handleSpeakerAudio(source, pos, volume, content);
Add arbitrary audio support to speakers (#982) Speakers can now play arbitrary PCM audio, sampled at 48kHz and with a resolution of 8 bits. Programs can build up buffers of audio locally, play it using `speaker.playAudio`, where it is encoded to DFPWM, sent across the network, decoded, and played on the client. `speaker.playAudio` may return false when a chunk of audio has been submitted but not yet sent to the client. In this case, the program should wait for a speaker_audio_empty event and try again, repeating until it works. While the API is a little odd, this gives us fantastic flexibility (we can play arbitrary streams of audio) while still being resilient in the presence of server lag (either TPS or on the computer thread). Some other notes: - There is a significant buffer on both the client and server, which means that sound take several seconds to finish after playing has started. One can force it to be stopped playing with the new `speaker.stop` call. - This also adds a `cc.audio.dfpwm` module, which allows encoding and decoding DFPWM1a audio files. - I spent so long writing the documentation for this. Who knows if it'll be helpful!
2021-12-13 22:56:59 +00:00
}
Add a MessageType for network messages Everything old is new again! CC's network message implementation has gone through several iterations: - Originally network messages were implemented with a single class, which held an packet id/type and and opaque blobs of data (as string/int/byte/NBT arrays), and a big switch statement to decode and process this data. - In 42d3901ee37892e259de26ebb57cf59ce284416e, we split the messages into different classes all inheriting from NetworkMessage - this bit we've stuck with ever since. Each packet had a `getId(): int` method, which returned the discriminator for this packet. - However, getId() was only used when registering the packet, not when sending, and so in ce0685c31f7315d15d3250c6c8605171b33aa99f we removed it, just passing in a constant integer at registration instead. - In 53abe5e56eec6840890770b6ec36a5d009357da7, we made some relatively minor changes to make the code more multi-loader/split-source friendly. However, this meant when we finally came to add Fabric support (8152f19b6efd71b66c3821ad94aacaddb7d26298), we had to re-implement a lot of Forge's network code. In 1.20.4, Forge moves to a system much closer to Fabric's (and indeed, Minecraft's own CustomPacketPayload), and so it makes sense to adapt to that now. As such, we: - Add a new MessageType interface. This is implemented by the loader-specific modules, and holds whatever information is needed to register the packet (e.g. discriminator, reader function). - Each NetworkMessage now has a type(): MessageType<?> function. This is used by the Fabric networking code (and for NeoForge's on 1.20.4) instead of a class lookup. - NetworkMessages now creates/stores these MessageType<T>s (much like we'd do for registries), and provides getters for the clientbound/serverbound messages. Mod initialisers then call these getters to register packets. - For Forge, this is relatively unchanged. For Fabric, we now `FabricPacket`s.
2024-01-03 09:15:38 +00:00
@Override
Update to 1.20.5 - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 19:17:43 +00:00
public CustomPacketPayload.Type<SpeakerAudioClientMessage> type() {
Add a MessageType for network messages Everything old is new again! CC's network message implementation has gone through several iterations: - Originally network messages were implemented with a single class, which held an packet id/type and and opaque blobs of data (as string/int/byte/NBT arrays), and a big switch statement to decode and process this data. - In 42d3901ee37892e259de26ebb57cf59ce284416e, we split the messages into different classes all inheriting from NetworkMessage - this bit we've stuck with ever since. Each packet had a `getId(): int` method, which returned the discriminator for this packet. - However, getId() was only used when registering the packet, not when sending, and so in ce0685c31f7315d15d3250c6c8605171b33aa99f we removed it, just passing in a constant integer at registration instead. - In 53abe5e56eec6840890770b6ec36a5d009357da7, we made some relatively minor changes to make the code more multi-loader/split-source friendly. However, this meant when we finally came to add Fabric support (8152f19b6efd71b66c3821ad94aacaddb7d26298), we had to re-implement a lot of Forge's network code. In 1.20.4, Forge moves to a system much closer to Fabric's (and indeed, Minecraft's own CustomPacketPayload), and so it makes sense to adapt to that now. As such, we: - Add a new MessageType interface. This is implemented by the loader-specific modules, and holds whatever information is needed to register the packet (e.g. discriminator, reader function). - Each NetworkMessage now has a type(): MessageType<?> function. This is used by the Fabric networking code (and for NeoForge's on 1.20.4) instead of a class lookup. - NetworkMessages now creates/stores these MessageType<T>s (much like we'd do for registries), and provides getters for the clientbound/serverbound messages. Mod initialisers then call these getters to register packets. - For Forge, this is relatively unchanged. For Fabric, we now `FabricPacket`s.
2024-01-03 09:15:38 +00:00
return NetworkMessages.SPEAKER_AUDIO;
}
Add arbitrary audio support to speakers (#982) Speakers can now play arbitrary PCM audio, sampled at 48kHz and with a resolution of 8 bits. Programs can build up buffers of audio locally, play it using `speaker.playAudio`, where it is encoded to DFPWM, sent across the network, decoded, and played on the client. `speaker.playAudio` may return false when a chunk of audio has been submitted but not yet sent to the client. In this case, the program should wait for a speaker_audio_empty event and try again, repeating until it works. While the API is a little odd, this gives us fantastic flexibility (we can play arbitrary streams of audio) while still being resilient in the presence of server lag (either TPS or on the computer thread). Some other notes: - There is a significant buffer on both the client and server, which means that sound take several seconds to finish after playing has started. One can force it to be stopped playing with the new `speaker.stop` call. - This also adds a `cc.audio.dfpwm` module, which allows encoding and decoding DFPWM1a audio files. - I spent so long writing the documentation for this. Who knows if it'll be helpful!
2021-12-13 22:56:59 +00:00
}