mp3streamer failed to allocate SharedArrayBuffer.

[stc1988]

Moddable: fece720,
Build environment: macOS,
Target device: M5stack

Steps to Reproduce

1. Build and install xamples/pins/audioout/mp3-http-stream using this build command: mcconfig -d -m -p esp32/m5stack ssid="wifi_ssid" password="wifi_passwod"
2. I got an error /Users/satoshi/Projects/moddable/examples/pins/audioout/mp3-http-stream/mp3streamer.js (160) # Break: SharedArrayBuffer: cannot allocate SharedArrayBuffer!.

Other information
M5stack core2 has no problem.

[phoddie]

Thanks for giving the new example a try.

The MP3 streaming uses some memory so it is not surprising there are memory failures in some environments. I don't have a an M5stack, but I will take a look on M5Stack Fire. Maybe they are similar enough.

[phoddie]

The mp3streamer example runs on M5Stack Fire by adding the following VM creation parameters to the application manifest:

	"creation": {
		"static": 32768,
		"chunk": {
			"initial": 1536,
			"incremental": 1536
		},
		"heap": {
			"initial": 128,
			"incremental": 64
		},
		"stack": 256
	}

I found a couple of other errors in the new MP3 examples while reviewing this. We'll push some fixes today or tomorrow for those as well. Thank you for your patience.

[phoddie]

Some improvements to the MP3 support have been committed:

• Adjustments to memory partitions to work in more situations
• Support for more MP3 streams (especially low-bit frames sometimes used in VBR encoding)
• Improved stream buffering strategy (collects more compressed bytes, to increase resilience against under flows)
• Local resources play all frames (previously stopped a few frames early)

I expect the memory use and buffering will continue to evolve as we gain experience using these implementations.

[stc1988]

Awesome work!! This change makes M5stack play mp3stream 👍

I can use elevenlabs TTS from stack-chan.

IMG_2529.MOV

[phoddie]

Wonderful. And the lip-sync even works!

[stc1988]

After this fix, examples/pins/audioout/elevenlabs-stream caught a memory full error in SSL handshake.

# Chunk allocation: failed for 304 bytes
XS abort: memory full

[phoddie]

I have't seen that myself. You can try adjusting the chunk allocation in the application manifest.

[stc1988]

I deleted creation section and it works in M5stack and M5stack core2.

[phoddie]

Interesting, OK. So, we can eliminate the custom creation. That's simpler.

FWIW – With the updates to the MP3 streaming support last week, the buffering changed a bit. Now, more MP3 compressed data is buffered instead of buffering it as uncompressed audio. That reduces the total amount of memory needed. The MP3 compressed data buffer is in the JavaScript heap, which may have stressed the smaller allocation just enough to cause failures in some cases.

To help reduce peak memory use, I made a small change to the mp3 streamer to defer allocation of the MP3 compressed data buffer until after the connection is established. The peak TLS memory use is during the handshake, while establishing the connection.