mirrors/CC-Tweaked
1
0
Fork 0
mirror of https://github.com/SquidDev-CC/CC-Tweaked synced 2025-11-26 09:54:49 +00:00
Code Issues Releases Wiki Activity

Enqueue audio when receiving it

Browse Source 
While Minecraft will automatically push a new buffer when one is
exhausted, this doesn't help if there's only a single buffer in the
queue, and you end up with stutter.

By enquing a buffer when receiving sound we ensure there's always
something queued. I'm not 100% happy with this solution, but it does
alleviate some of the concerns in #993.

Also reduce the size of the client buffer to 0.5s from 1.5s. This is
still enough to ensure seamless audio when the server is running slow (I
tested at 13 tps, but should be able to go much worse).
This commit is contained in:
Jonathan Coates
2021-12-19 19:50:43 +00:00
parent 8a1067940d
commit aa36b49c50
7 changed files with 35 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
src/main/java/dan200/computercraft/shared/peripheral/speaker/DfpwmState.java
View File

@@ -28,7 +28,7 @@ class DfpwmState
* The minimum size of the client's audio buffer. Once we have less than this on the client, we should send another
* batch of audio.
*/
private static final long CLIENT_BUFFER = (long) (SECOND * 1.5);
private static final long CLIENT_BUFFER = (long) (SECOND * 0.5);
private static final int PREC = 10;

2
src/main/java/dan200/computercraft/shared/peripheral/speaker/SpeakerPeripheral.java
View File

@@ -343,7 +343,7 @@ public abstract class SpeakerPeripheral implements IPeripheral
// TODO: Use ArgumentHelpers instead?
int length = audio.length();
if( length <= 0 ) throw new LuaException( "Cannot play empty audio" );
if( length > 1024 * 16 * 8 ) throw new LuaException( "Audio data is too large" );
if( length > 128 * 1024 ) throw new LuaException( "Audio data is too large" );
DfpwmState state;
synchronized( lock )