I Put NAM A2-Lite Inside an iRig HD X · TaurusTAURUSBlogExploreLegalContact usExploreBlogFeaturesThe hostPricingFAQLegalPrivacy PolicyTerms & ConditionsImprintSupportContact ussupport@playtaurus.comGet Taurus← All postsAug 30, 2026 · EngineeringI Put NAM A2-Lite Inside an iRig HD XThe USB interface already had a 500 MHz Cortex-M7 inside it. I replaced its firmware, fitted A2-Lite into 128 KiB of FlexRAM, and measured the physical device against upstream NAMCore at −115.6 dB.I Put NAM A2-Lite Inside an iRig HD X
The iRig HD X on my desk used to send guitar audio to another computer for processing. It does the amp modelling itself now.
Guitar → iRig codec → NAM A2-Lite → headphones or amplifier
The model runs on the 500 MHz microcontroller already inside the interface. USB supplies power. The wheel still controls the headphone volume. The sound coming out is a 5150 capture with an OD808 in front, rendered in real time inside the iRig.

Photo from IK Multimedia's official iRig HD X image gallery.
There was a computer in the interface
This started immediately after I rewrote the HD X's USB audio path. That work made the interface usable with the ESP32-S3 in my pedal prototype. Once I had a firmware readback and understood how the box moved audio, the larger chip on the board became hard to ignore.
The HD X is built around an NXP MIMXRT1011DAE5A: a 500 MHz Cortex-M7 with hardware floating point, tightly coupled memory, external QSPI flash, SAI audio and eDMA. Its normal job is to configure the codec, move samples and handle the controls. Most of the processor was waiting between audio interrupts.
NAM A2-Lite was designed for exactly this kind of machine. It is the compact member of the A2 family we use in Taurus: one recurrent amp model and 48 kHz audio. I used a 5150 capture with an OD808 in front by jp_is_out_of_tune that I had found online—the same model I had been using throughout the embedded tests.
I wanted the whole path inside the interface. The codec would capture the guitar, the RT1011 would run the model, and the codec would play the result. The ESP32-S3, Mac and phone could all disappear from the audio path.
Fitting the engine into 128 KiB
The processor has four 32 KiB FlexRAM banks. Those banks can become instruction TCM, data TCM or ordinary on-chip RAM at boot. A2-Lite's engine object takes 91,204 bytes, so the usual memory layout was useless.
I configured three banks as DTCM and one as OCRAM:
RegionSizeWhat lives thereDTCM96 KiBA2-Lite weights and convolution historyOCRAM32 KiBDMA buffers, program data and stackExternal QSPI2 MiBExecutable code, constants and the model file
The compact model is 7,516 bytes. It stays in flash until startup, then its weights and history land in DTCM. The final live build uses 91,232 bytes of DTCM, leaving 7,072 bytes free. OCRAM usage, including the reserved stack, is 10,664 bytes. That leaves 22,104 bytes for the audio machinery and anything else the firmware needs to survive.
From 48 frames to 16
I brought the engine up with 48-sample blocks. At 48 kHz, each block lasts one millisecond and gives a 500 MHz processor 500,000 cycles.
The physical null-test run measured:
48-sample blockCyclesMinimum442,052Mean442,108Maximum442,260Deadline500,000
The worst block used 88.45% of the available time and returned with 57,740 cycles left.
I tried the Cortex-M7's DSP instructions first. A staged layer-major implementation took 662,042 cycles. My hand-written two-frame convolution kernel took 1,001,381. Both missed the audio deadline.
The fastest version was the portable whole-model floating-point engine. The M7's cache, FPU and compiler already agreed on a better schedule than my manual kernels. I removed the clever code and kept the version that finished on time.
I later cut the live buffer to 16 frames, or 0.333 ms. Its deadline is 166,667 cycles. The final firmware keeps streaming through a late block. If either four-entry DMA queue falls behind, it restarts both SAI streams; a fault becomes an audible click or dropout and playback resumes.
Turning the interface into the pedal
The replacement firmware configures the original codec over I2C and streams stereo audio through SAI with eDMA. Each completed input block is converted to float, fed through A2-Lite, converted back and queued for playback. The second output channel carries the same processed signal so the headphone and amplifier paths behave normally.
The physical wheel continues to set headphone level. This became urgent when the first live build came up painfully loud. Once the wheel worked again, I could play it like the original interface.
In live mode the USB cable powers the HD X. Audio stays on the board:

The codec samples the guitar at 48 kHz.
eDMA fills a 16-frame input block.
A2-Lite renders the 5150 capture.
eDMA sends the result back to the codec.
The headphone and amp outputs play it.

I plugged a guitar and headphones into the iRig and heard the model with no host computer in the signal path. The USB interface had become the entire pedal.
Against upstream NAMCore
I rendered the same 15-second, 48 kHz guitar recording through upstream NeuralAmpModelerCore using the original .nam capture. A temporary iRig firmware returned the RT1011's processed samples over USB for comparison; I restored the live firmware after recording them.
The physical iRig and upstream NAMCore aligned at zero samples. Here is the null over the steady part of the render, after the first second:
MeasurementResultRelative null−115.63 dBCorrelation0.9999999999985Largest sample error2.811 × 10⁻⁶ (−111.0 dBFS)Residual RMS−131.83 dBFS
Hear all four filesThe rendersThe same 15-second DI through upstream NAMCore and the physical RT1011 inside the iRig. Both play at unity gain.NAMCore−16.16 dBFS rmsThe original capture rendered by upstream NeuralAmpModelerCore.iRig HD X−16.16 dBFS rmsThe same capture rendered inside the physical iRig.The nullNAMCore minus the iRig, sample by sample. The second player adds 80 dB so the residue can be heard.Null at unity gain−131.86 dBFS rmsThe complete difference at its real level.Null +80 dB−51.86 dBFS rmsThe same null multiplied by 10,000. Lower your volume before playing it.All four waveforms share one absolute scale. The +80 dB file changes only listening gain; its samples are the unity-gain null multiplied by 10,000.Across the complete 15 seconds, including startup, the relative null was −115.70 dB. The largest error was a few millionths of full scale. That is floating-point rounding from a different compiler and processor, far below the codec's analogue noise floor.
The box on my desk is different now
An iRig HD X is sold as the bridge between a guitar and software running somewhere else. This one can run the amp model inside its own audio loop.
The finished research build has:

the real NAM A2-Lite engine;
a 5150 + OD808 capture stored in its own flash;
48 kHz processing in 16-frame, 0.333 ms blocks;
automatic SAI/eDMA recovery instead of permanent silence after an underrun;
the original codec, input, outputs and volume wheel; and
a −115.63 dB null against upstream NAMCore.

I began this trip trying to make the wrong USB interface talk to an ESP32-S3. About twelve hours later, the interface could make the amp sound by itself.NextA2-Full on an ESP32-S3 Shouldn't FitCoyotiv © 2026Privacy PolicyTerms & ConditionsImprintSupport

The research detailed by the author focused on integrating the NAM A2-Lite engine into the iRig HD X USB interface to enable real-time amp modeling directly within the audio signal path, aiming to remove the need for an external host computer. The initial setup utilized the existing microcontroller within the interface, which is based on a 500 MHz Cortex-M7 with hardware floating point capabilities. The objective was to create a self-contained system where guitar audio would be captured, processed by the model, and played back, thereby eliminating external dependencies like a computer or an ESP32-S3. The proposed audio flow is guitar signal through the iRig codec to the NAM A2-Lite engine, which renders the result before sending it to headphones or an amplifier.

The integration required optimizing the compact A2-Lite model to fit within the system's memory constraints. The processor utilized four 32 KiB FlexRAM banks, which were configured to serve as instruction TCM, data TCM, or ordinary RAM during startup. The memory layout for the engine weights and convolution history was managed by allocating portions of these banks as Dynamic TCM (DTCM) and On-Chip RAM (OCRAM). The specific configuration allocated 96 KiB to DTCM for weights and history, 32 KiB for OCRAM storing DMA buffers and program data, and 2 MiB for external QSPI flash for the executable code and model file. The optimized model size was significantly smaller, requiring only 7,516 bytes of storage, with the final live build utilizing 91,232 bytes of DTCM.

Performance evaluation focused on meeting the real-time latency requirements of the audio stream. The processing engine was tested using 48-sample blocks, where each block corresponded to one millisecond at the operational sampling rate of 48 kHz, demanding 500,000 cycles from the 500 MHz processor. Initial attempts using manually written convolution kernels proved insufficient, failing to meet the processing deadline. The successful implementation relied on optimizing the internal floating-point engine, leveraging the Cortex-M7’s cache and FPU capabilities. The fastest execution was achieved by adopting a portable whole-model floating-point engine, which successfully operated within the time constraints. Further refinement reduced the live buffer size to 16 frames, ensuring the system could handle potential underruns by automatically restarting the SAI streams upon a fault, preventing audible dropouts.

The replacement firmware configured the original codec via I2C and streamed stereo audio through SAI with eDMA. Each input block was converted to floating-point, processed by the A2-Lite, converted back, and queued for playback, ensuring simultaneous operation across the headphone and amplifier outputs. In live mode, the system demonstrated autonomous operation where the USB interface became the entire pedal, performing signal capture, model rendering, and output generation without an external computer.

Validation against upstream processing was conducted by comparing the results against the upstream NeuralAmpModelerCore. A null measurement was obtained by comparing the render from the physical iRig against the upstream model. This measurement yielded a relative null of -115.63 dB compared to the upstream NAMCore. The comparison demonstrated high correlation between the physical hardware execution and the upstream model, with the largest sample error being extremely small, indicating that the physical implementation aligned closely with the upstream calculation, falling well below the codec's analogue noise floor. Ultimately, the finished research build successfully integrated the NAM A2-Lite engine, a 5150 plus OD808 capture, and real-time 48 kHz processing into the iRig HD X, establishing a system where the hardware performed the amp modeling autonomously with high fidelity.