Streaming playback stops unexpectedly — Simple fix proposed

[MidnightJava]

I'm using aurora-websocket to stream data to aurora.js from a server. The server sends data indefinitely, but after anywhere from 5 seconds to a minute, the audio playback stops.

Javascript debugging shows me that aurora-websocket continues to receive data from the WebSocketServer and emit data events to aurora's WebSocketSource, even after audio playback has stopped. I traced the event firing through aurora.js, and ultimately found what seems like a bug. I made a one-line change, and it solved my problem. However, I'm not sure I fully understand the way events are supposed to work in aurora.js, so perhaps this is not the best way to fix it.

A diff of the change is pasted below. Here's a summary of it.

When decode() is invoked, it first sets waiting to false. It sets it to true again if readChunk() does not return a packet and the final buffer has not been received. If readChunk does return a packet, the Decoder emits a 'data' event, but it does not set waiting to true.

This causes a problem in the 'data' event handler for demuxer (decoder.js line 42). After several seconds of processing, it reaches a state where 'data' events are received, but it is impossible to invoke decode(), because waiting is false and can never be true again. It can only be set to true if decode() is invoked, but decode() cannot be invoked unless waiting is true. So the processing is deadlocked, and incoming packets are not decoded.

My fix simply sets this.waiting = true when a packet is returned from readChunk() (line 82 of the patched code)

diff --git a/src/decoder.js b/src/decoder.js
index c3499a4..67b8efc 100644
--- a/src/decoder.js
+++ b/src/decoder.js
@@ -79,6 +79,7 @@
       }
       if (packet) {
         this.emit('data', packet);
+   this.waiting = true;
         return true;
       } else if (!this.receivedFinalBuffer) {
         this.bitstream.seek(offset);

[devongovett]

I think, without testing, that this would cause the decoder to decode as fast as possible, rather than decoding only as needed (i.e. when the player needs more data).

The player, or really the queue which is used by the player, calls decode when it needs more packets. If a chunk couldn't be decoded, waiting is set to true so that as soon as more data comes in, decoding resumes. If we set waiting to true after every chunk, decoding would happen as fast as data arrived, rather than only as needed by the player.

What you're probably running into instead is that the player stops the audio output device (and playback clock) when it runs out of data. I think it currently doesn't start the clock up again after more data comes in (the real bug). Can you try commenting out the line I linked to and testing? The clock won't pause while more data comes in, but you'll be able to test and see if it starts up again.

[MidnightJava]

Thanks, I removed the one-line change I made above, and commented out _this.device.stop in the concatenated javascript file, and the behavior is still the same. Audio playback stops after several seconds.

[mhavryliv]

I'm running into the same issue, and MidinghtJava's initial comment didn't solve it, but commenting out _this.device.stop() does. I suffer slight glitches when running short on data, but it keeps running.

Out of interest, where would I look for if I was to try writing code to start the clock up again after more data comes in?

[ajenkul]

Same problem here @devongovett . I've tried @MidnightJava solution but not work, it always stop unexpected. I don't know has this problem been solved yet?
@mhavryliv I tried to find _this.device.stop() and comment it but not work too.