Use AC79 CPU1 for realtime DSP processing

[gospodindilly-ops]

I have been looking into the CPU load of Felucca and whether the second CPU core of the AC79 could be used for additional DSP processing.

It looks like this is actually supported by the AC79 hardware and by the official JieLi SDK documentation, rather than being an undocumented/hypothetical feature.

The official AC79 documentation describes a dual-core mode where CPU0 runs the system and CPU1 is dedicated to a separate user function:

https://doc.zh-jieli.com/AC79/zh-cn/master/module_example/system/%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E5%8D%95%E5%8F%8C%E6%A0%B8%E4%BD%BF%E7%94%A8%E6%96%B9%E6%B3%95.html

The same documentation explicitly describes cpu1_main(), CPU0/CPU1 synchronization using spin_lock, and notes that CPU1 can be kept idle when it has no work in order to reduce power consumption.

The AC79 documentation also confirms that interrupts can be assigned to either CPU, including software interrupts:

https://doc.zh-jieli.com/AC79/zh-cn/release_v1.0.3/module_example/system/interrupt.html

For example, request_irq() has a cpu_id parameter where 0 selects CPU0 and 1 selects CPU1, and IRQ_SOFT0..IRQ_SOFT7 are available. This seems suitable for a small CPU0 → CPU1 DSP job queue.

The AC79 itself is officially specified as a dual-core DSP up to 320 MHz with hardware math acceleration, cache and 578 KB SRAM:

https://doc.zh-jieli.com/AC79/zh-cn/master/getting_started/overview/index.html

Possible Felucca architecture

I think we could keep the existing realtime audio pipeline on CPU0 and move only selected expensive DSP engines to CPU1.

For example:

CPU0
MIDI / sequencer
voice allocation
modulation
light engines
mixer / final output
|
DSP job queue + software IRQ
v
CPU1
GRAIN
heavy filters / physical modelling
possibly reverb or other expensive DSP
|
v
shared audio buffer
|
v
CPU0

I would start with a very small proof of concept:

1. Boot CPU1.
2. Run a simple CPU1 heartbeat/test function.
3. Implement a shared-memory queue between CPU0 and CPU1.
4. Wake CPU1 using a software interrupt.
5. Implement a CPU0 → CPU1 → CPU0 audio passthrough.
6. Move only one engine, probably GRAIN, after the transport is proven stable.

This should allow us to verify the architecture without changing the whole audio system at once.

One important caveat from the JieLi documentation is that CPU1 can be suspended during Flash writes. If CPU1 must continue running during Flash operations, its code and called functions need to be placed in internal RAM/SDRAM:

https://doc.zh-jieli.com/AC79/zh-cn/master/module_example/system/%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F%E5%8D%95%E5%8F%8C%E6%A0%B8%E4%BD%BF%E7%94%A8%E6%96%B9%E6%B3%95.html

So this would require some careful linker/memory work.

Power consumption

Obviously, using CPU1 continuously will increase power consumption compared with leaving it idle. However, the official documentation explicitly mentions using idle on CPU1 to reduce power when there is no work.

For Felucca, the goal would therefore not be to run CPU1 continuously at 100%, but to use it for expensive DSP blocks and let it idle when possible.

How difficult would this be?

I would expect the initial CPU1 proof-of-concept to be relatively manageable, while moving the actual DSP engines is more involved because of shared state, audio-buffer ownership, cache/memory synchronization and realtime deadlines.

I think the safest approach is to first prove:

CPU1 boot → shared queue → software IRQ → DSP job → audio buffer

and only then migrate GRAIN or another expensive engine.

Would you be interested in this approach?

[nullpainter]

Unlocking both cores feels like it could be a game changer in Felucca's direction and decision-making, as it would make previously impractical synthesis feasible.

[gospodindilly-ops]

https://github.com/charlesvestal/fm1-x0x/releases/tag/v1.0 HE IS DO that)))

[gospodindilly-ops]

I’ve been looking into the dual-core work in X0X and thinking about a different way to use the second CPU core in Felucca.

Rather than assigning specific synth engines to CPU0 and CPU1 as X0X does, could we split the DSP workload by groups of voices within an audio block?

My proposed approach:

1. Reuse and adapt X0X’s low-level CPU1 startup, stack setup and task synchronization mechanisms.
2. Keep CPU0 as the main audio/control core, responsible for the audio pipeline and final mixing.
3. Investigate splitting active voices into two groups: CPU0 renders one group, while CPU1 renders the other.
4. Give each core its own output buffer to avoid concurrent writes to the same mix buffer. CPU0 combines the results after CPU1 finishes.
5. Make the worker synchronization deadline-aware. CPU1 must finish before the next DMA audio deadline, with no underruns or audible glitches.
6. Start with a minimal CPU1 test, then prototype parallel rendering and compare its output against the current single-core build.

This would be a different workload-partitioning strategy from X0X’s engine-based split. It might also make the workload easier to balance when different engines have very different CPU costs, although voice-level splitting would need careful handling of engine state, effects and shared resources.

References:

• X0X dual-core design notes: https://github.com/charlesvestal/fm1-x0x/blob/v1.0/docs/plans/2026-10-04-dual-core-and-clock.md
• CPU1 interface: https://github.com/charlesvestal/fm1-x0x/blob/v1.0/firmware/hal/fm1_cpu1.h
• CPU1 assembly startup: https://github.com/charlesvestal/fm1-x0x/blob/v1.0/firmware/hal/fm1_cpu1.S
• X0X DSP scheduling: https://github.com/charlesvestal/fm1-x0x/blob/v1.0/firmware/src/app/engine.c#L539-L686
• Felucca audio path: https://github.com/hugelton/Felucca/blob/main/firmware/src/audio.c

This is just an architectural proposal. The first step would be to check whether Felucca’s voice rendering can be safely separated without changing sound behavior, and benchmark the result on real hardware.

[gospodindilly-ops]

https://github.com/keremimo/melodee/releases/tag/v1.1.0

[kurogedelic]

Thanks for the research. I'll consider using CPU1 in Felucca. If you know of a solid fork that does this well, please let me know.

[edco]

I've been developing my SMK-37 Pro firmware with Core 1 as a dedicated DSP core from day 1. Sample generation/processing lives on Core 1, and pretty much everything else runs on Core 0. It happily does 16 voice polyphony with MSFA/Dexed at 48kHz running at the "max" core speed of 320MHz, and I'm pretty sure there are more code optimisations that could be made. This morning I applied the same overclock to 360MHz that M-VAVE uses, so now there's a bunch of extra headroom on top of that.

I'm just cleaning up the repo, making sure I'm complying with the various licences etc. - aiming to open it up within 36 hours.

Fair warning though, it's not super polished. It's also a bit of an architectural shift from how M-VAVE did things, and imposes some restrictions that may require a bit of rework in your code.

[gospodindilly-ops]

Hi Leo! I've got exactly this running, with the per-block split I suggested above. It's in my own Felucca fork (based on 1.5.1, private for now), and it works on my FM-1.

How it works: each audio block, the four parts are split between the cores by their last-block cost. CPU1 renders its parts into its own sums, and CPU0 adds them in, then runs the FX and master as before. The low-level side (CPU1 start, the RAM waiting loop, a check-word mailbox, core-1 guards) is from X0X 1.0.5. The split and the hardening follow Jangada's. There is no voltage boost.

How I tested it:

• Same sound: the output is bit-for-bit identical to one core. A host test renders 4 parts of every preset of every engine, plus mixes with INSERT, SLICER, SPREAD, the matrix and S&H, on one core and with a thread playing core 1 over every split. All 88 golden renders also match that way. It is clean under ThreadSanitizer, which flags a shared buffer at once when I put one back on purpose.
• On my FM-1, heavy project, 2 cores vs 1: CPU load about 23 % vs 40 %, slowest audio half 1.57 ms vs 1.86 ms. Over 8 minutes: 0 core-1 misreads, 0 late halves, no crashes.
• Safety: if core 1 ever misreads or stops answering, it falls back to one core by itself and stays off (MENU > SYSTEM > 2ND CORE AUTO / OFF).

I'm porting it onto 1.6 now and will open a PR in a day or so. Would you rather have it on by default (AUTO) or opt-in?

[gospodindilly-ops]

Here it is, on Felucca 1.6: #247

One commit, only the second core. Tested on my FM-1 with a heavy 4-track project: 2ND CORE AUTO 35–51 % load, no late halves; OFF (one core) 65–74 % and the audio ran late. All host tests pass, plus a new dual-core test (every preset of every engine, SAMPLE and SLICE included, bit for bit over every split) and ThreadSanitizer. AUTO is the default; it turns itself OFF on a unit whose core 1 misreads. Happy to change that to opt-in if you prefer.

[edco]

I'm just cleaning up the repo, making sure I'm complying with the various licences etc. - aiming to open it up within 36 hours.

Well that self imposed deadline came and went. I should have it up within a day though. I hadn't looked at your codebase before, and didn't realise you're not using FreeRTOS, so that's already a substantial difference that might be hard to accommodate (though it's not fundamental to the dual core approach). Still, you might find some useful architectural ideas in my version.

[etyrnal]

I have been looking into the CPU load of Felucca and whether the second CPU core of the AC79 could be used for additional DSP processing.

It looks like this is actually supported by the AC79 hardware and by the official JieLi SDK documentation, rather than being an undocumented/hypothetical feature.

The official AC79 documentation describes a dual-core mode where CPU0 runs the system and CPU1 is dedicated to a separate user function:

my first instantaneous thought when i saw the dsp capability of the proc was exactly THIS... especially for pitch/time/formant effects.

I would immediately add a good granular effect with about 3 or 4 pages of parameters ... especially with diffusion, randomization for panning slices, and adjustable rando reverse, etc.

Then the dsp could also be used to stretch samples in real time etc.