You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, great job on aurora and the mp3 decoder!
I also experienced major audio glitches when using the mp3 decoder with a WebSocket data source. I suspect this happens when the bit reservoir is used, specifically when a frame uses data that is part of a frame in that was received in the previous chunk of raw data.
If I send more MP3 frames (50-100) per websocket chunk, the glitches occur less frequently. If I send one MP3 frame per websocket chunk, no audio is ever decoded. I think the bit reservoir may get lost between processing of input chunks.
I also had to comment out the "throw new Error('bad main_data_begin pointer');" line in Layer3.prototype.decode, and add some code to skip the call to decodeMainData in this case. If the exception is thrown, it seems that the bit reservoir is never filled. While the first frame (using the bit reservoir) can not be decoded, it should not be discarded because it may be needed for following frames.
@DeusExLibris that's great news! Thank you very much for the patch, I'll definitely test it some time. In the meantime I have been exploring alternative options like Media Source Extensions and AudioContext.decodeAudioData, but both have problems of their own.
@UCIS I found that decodeAudioData is unreliable (at least on Chrome) for decoding mp3 files and abandoned that approach. In retrospect, it may have been caused by the same issue that I had with aurora with live streams. I am using ffmpeg to encode the audio and by default it enables the bit reservoir. In this instance, if you come in the middle of a stream (as opposed to playing it from the beginning), the first frames will likely have a main_data_begin pointer to frames that were sent before the player started receiving data. I solved this by setting the "-reservoir 0" flag on ffmpeg and it fixed the issue. Also, I have updated my aurora fork to include my websocket code (one that uses a web worker for the websockets and one that doesn't). You can find that code here.
First of all, great job on aurora and the mp3 decoder!
I also experienced major audio glitches when using the mp3 decoder with a WebSocket data source. I suspect this happens when the bit reservoir is used, specifically when a frame uses data that is part of a frame in that was received in the previous chunk of raw data.
If I send more MP3 frames (50-100) per websocket chunk, the glitches occur less frequently. If I send one MP3 frame per websocket chunk, no audio is ever decoded. I think the bit reservoir may get lost between processing of input chunks.
I also had to comment out the "throw new Error('bad main_data_begin pointer');" line in Layer3.prototype.decode, and add some code to skip the call to decodeMainData in this case. If the exception is thrown, it seems that the bit reservoir is never filled. While the first frame (using the bit reservoir) can not be decoded, it should not be discarded because it may be needed for following frames.
This issue may be related to #5.
The text was updated successfully, but these errors were encountered: