Core Audio Packs And Storage Update

Today’s Core work was about turning a useful bench setup into a more coherent device model.

The headline change is audio.

The more important change is what had to happen around it to make that audio practical.

Spoken audio is no longer compiled into the firmware

Until now, spoken callouts still depended too much on linker-embedded PCM assets.

That worked as a bring-up strategy, but it was the wrong long-term model.

It kept too much voice content inside the app image, made the firmware heavier than it needed to be, and left the platform stuck between “real audio packs” and “legacy embedded speech.”

That has now changed.

Core now loads spoken audio from installable audio packs on internal storage.

That means:

• startup audio can come from the active pack
• event and status callouts can come from the same pack path
• and firmware is no longer carrying the full spoken library as compiled-in assets

This is a more serious architecture. It makes voice selection, pack updates, and future audio customization behave like content management instead of firmware surgery.

File import is now part of the normal firmware model

The audio-pack work only really matters if getting files onto Core is practical.

That is where the import workflow became important.

Earlier replay validation proved that Core could expose its internal storage for file import, but the workflow still depended on special builds and too much reflashing. That was fine for proving the concept. It was not a good ongoing development or product path.

Core now uses a more intentional model:

• normal firmware boots normally
• APEXCORE can be exposed when needed
• files can be copied onto the mounted drive
• eject returns storage to firmware ownership
• and replay can run from the imported files without switching into a separate dedicated firmware image

That is a much better foundation.

It reduces friction for development, but it also matters for the user-facing story because USB storage is no longer being treated as a one-off bench trick. It is becoming part of how Core can accept managed content.

Replay became more practical too

That same USB path also became more useful for replay.

Replay now supports 1x, 2x, and 4x speed control through a simple sidecar config, and the post-replay return path is more predictable than it was during the earlier USB storage experiments.

That matters because replay is not just a debugging toy anymore.

It is part of how Core behavior gets validated:

• log generation
• summary behavior
• audio-callout timing
• and storage/offload behavior

Making that loop easier makes the device more trustworthy faster.

Storage finally matches the content model

The most practical part of today’s work was resizing Core’s flash partitions.

Once spoken audio moved into packs, the storage problem became obvious:

• the Joanna pack is large enough to matter
• realistic replay files are large enough to matter
• and the old APEXCORE storage allocation was too small to hold both at the same time

That is not just an inconvenience. It is a sign that the content model and the flash layout are out of sync.

Core now uses a rebalanced storage layout that gives more space to the storage area while still leaving comfortable OTA headroom for the current firmware image.

The result is the practical one that matters:

• audio_pack.bin fits
• replay files fit
• and the device can now hold the kind of combination the workflow actually needs

That includes both short and long replay validation with the active voice pack present on the same storage volume.

Why this matters

This is one of those updates that looks narrower than it really is.

It is easy to describe as “audio packs now work.”

The deeper truth is that Core got a more believable content pipeline:

• content can live on-device instead of in the binary
• storage can actually hold the files the workflow depends on
• USB import is part of the normal firmware behavior
• and replay remains available as a validation tool instead of being crowded out by the new audio model

That is closer to how a real product platform should behave.

What is next

The obvious next step is Companion-side management.

Now that Core can use installable audio packs and ingest them through APEXCORE, the next product question is how Companion should let the user choose, load, and manage those packs cleanly.

There is also still one smaller behavior question left open on Core: whether automatic return to normal mode after replay should play the startup sound again or stay quiet.

That is worth deciding separately.

But the larger milestone is already clear:

Core spoken audio is no longer trapped inside the firmware image, and the device now has a storage and import model that can support what comes next.