The Beginning: A Challenge Wrapped in an Opportunity

Pushing the SpacemiT K3 to the Limit: Vectorizing AudioMark for RISC-V"

When I started exploring RISC-V Vector extension (RVV) optimization, I had no idea I'd end up spending weeks wrestling with vector intrinsics, Docker containers, and QEMU emulation. But that's exactly what happened , and the results were beyond anything I expected.

The goal was deceptively simple: Port EEMBC's AudioMark benchmark to RISC-V and optimize it using the Vector extension (RVV).

AudioMark is an industry-standard benchmark that measures audio processing performance through four key components:

• Beamforming (ABF) — Combining signals from multiple microphones

• Acoustic Echo Cancellation (AEC) — Removing echo in real-time

• Noise Reduction (ANR) — Filtering background noise

• Keyword Spotting (KWS) — "Hey Siri" style voice detection

The catch? AudioMark was designed for ARM processors with CMSIS-DSP. RISC-V had no optimized port. Until now.

Project Overview:

PS: My drawings look like hieroglyphs. The code is readable, though

Phase 1: Foundation

• Built the RISC-V GCC cross-compiler toolchain from source

• Created a scalar (non-vectorized) baseline to measure initial performance

• Result: 641 AudioMarks — our starting point

Phase 2: Optimization

• Studied VOLK (Vector-Optimized Library of Kernels) to learn proven RVV patterns

• Implemented 12 vectorized DSP functions using RVV 1.0 intrinsics

• Dockerized the entire toolchain for easy reproducibility

Phase 3: Validation

• Tested on QEMU emulator with RVV enabled

• Sent static binary to real SpacemiT K3 hardware for validation

• Result: 35,418 AudioMarks — a 55x improvement over baseline!

Phase 1: The "Brain Without a Body" Problem

The Painful First Steps

My first attempt was... humbling. I built the RISC-V GCC toolchain from source:

git clone https://github.com/riscv-collab/riscv-gnu-toolchain
cd riscv-gnu-toolchain
./configure --prefix=/opt/riscv --disable-gdb
make linux -j$(nproc)  # 45 minutes later...

The compiler worked! I could cross-compile for RISC-V. But when I tried to run my binary on QEMU:

$ qemu-riscv64-static ./my_program
./my_program: error while loading shared libraries: libc.so.6: cannot open shared object file

The sysroot was missing. I had built a brain (the compiler) but forgot the body (the C library).

After hours of debugging, I discovered the CMAKE_SYSROOT variable and pointed it to /opt/riscv/sysroot. Finally, my "Hello World" ran on QEMU.

$ qemu-riscv64-static -L /opt/riscv/sysroot ./hello
Hello from RISC-V!

My first scalar AudioMark score: 641 AudioMarks.

Not impressive. But it was a baseline.

*You can give it a read here (Its fun)-
*From Scratch to Sysroot: Porting the EEMBC AudioMark Benchmark to RISC-V Linux

Milestone 1: The Portable Lab — Dockerizing Everything

The Problem with "Works on My Machine"

Feedback from the RISC-V community was clear: "If someone wants to run your code on their Banana Pi F3, they shouldn't spend 60 minutes building a toolchain."

He was right. My setup was fragile. One wrong environment variable, one missing library, and everything breaks. The solution? Docker.

Building the Ultimate RISC-V Development Container

I created a multi-stage Dockerfile that:

1. Stage 1 (Builder): Builds the RISC-V toolchain and QEMU 8.2 from source

2. Stage 2 (Final): Contains only the compiled binaries (~1GB instead of 5GB)

Now anyone could run:

docker pull ayushd785/riscv-audio-lab
docker run -it -v $(pwd):/work riscv-audio-lab
# Instant RISC-V development environment!

Milestone 2: Learning from the Masters — Analyzing VOLK

Before writing a single line of RVV code, I studied how the experts did it. VOLK (Vector-Optimized Library of Kernels) had recently merged an RVV port by Olaf Bernstein in PR #774.

The Four "Cheat Codes" I Discovered

Cheat Code #1: Strip-Mining (VLEN Independence)

RISC-V Vector doesn't have a fixed vector length. Different chips have different VLEN:

• SpacemiT K1: VLEN=128 (16 bytes)

• SiFive: VLEN=256 (32 bytes)

• Future chips: VLEN=512+

How do you write code that works on ALL of them? Strip-mining.

// The magic loop pattern
size_t vl;
for (; n > 0; n -= vl, x += vl, y += vl, z += vl) {
    vl = __riscv_vsetvl_e32m8(n);  // Ask: "How many elements can you handle?"
    // Process 'vl' elements...
}

The vsetvl instruction queries the hardware at runtime. Your code automatically adapts to any VLEN without recompilation!

Cheat Code #2: LMUL (Register Grouping)

LMUL controls how many vector registers are grouped together:

• LMUL=1: Use 1 register per operand (8 available)

• LMUL=8: Group 8 registers together (maximum throughput)

For simple operations like addition, use LMUL=8:

vfloat32m8_t vx = __riscv_vle32_v_f32m8(x, vl);  // m8 = LMUL=8
vfloat32m8_t vy = __riscv_vle32_v_f32m8(y, vl);
vfloat32m8_t vz = __riscv_vfadd_vv_f32m8(vx, vy, vl);
__riscv_vse32_v_f32m8(z, vz, vl);

Cheat Code #3: Deferred Reduction (Dot Products)

The naive approach reduces to scalar on every iteration — expensive!

// WRONG: Scalar reduction every iteration (slow)
float sum = 0;
for (int i = 0; i < n; i++) {
    sum += a[i] * b[i];
}

The VOLK pattern: accumulate in vectors, reduce once at the end:

// RIGHT: Vector accumulation, single reduction
vfloat32m8_t v_sum = __riscv_vfmv_v_f_f32m8(0.0f, __riscv_vsetvlmax_e32m8());

for (; n > 0; n -= vl, x += vl, y += vl) {
    vl = __riscv_vsetvl_e32m8(n);
    vfloat32m8_t vx = __riscv_vle32_v_f32m8(x, vl);
    vfloat32m8_t vy = __riscv_vle32_v_f32m8(y, vl);
    v_sum = __riscv_vfmacc_vv_f32m8(v_sum, vx, vy, vl);  // FMA into accumulator
}

// Single horizontal reduction
vfloat32m1_t v_zero = __riscv_vfmv_v_f_f32m1(0.0f, 1);
vfloat32m1_t v_result = __riscv_vfredusum_vs_f32m8_f32m1(v_sum, v_zero, __riscv_vsetvlmax_e32m8());
float result = __riscv_vfmv_f_s_f32m1_f32(v_result);

Cheat Code #4: Segmented Loads (Complex Numbers)

Complex numbers are stored interleaved: [Real0, Imag0, Real1, Imag1, ...]

Normal loads would mix real and imaginary parts. The solution? Segmented loads:

// Magic: Loads into two separate registers automatically!
vfloat32m4x2_t vx = __riscv_vlseg2e32_v_f32m4x2(ptr, vl);
vfloat32m4_t real = __riscv_vget_v_f32m4x2_f32m4(vx, 0);
vfloat32m4_t imag = __riscv_vget_v_f32m4x2_f32m4(vx, 1);

This single instruction de-interleaves complex numbers across two vector register groups.

Milestone 3: The Engine Upgrade — Implementing RVV Kernels

Armed with the VOLK cheat codes, I created audiomark/ports/riscv/th_api.c — the heart of my optimization.

The Functions I Vectorized

The "Boss Fight": Complex Multiplication

Complex multiplication is the most computationally intensive operation in audio processing. The formula:

(a + bi) × (c + di) = (ac - bd) + (ad + bc)i

My vectorized implementation:

void th_cmplx_mult_cmplx_f32(const float *x, const float *y, float *z, uint32_t len) {
    size_t vl;
    int n = (int)len;

    for (; n > 0; n -= vl, x += 2*vl, y += 2*vl, z += 2*vl) {
        vl = __riscv_vsetvl_e32m4(n);

        // De-interleave: load [R0,I0,R1,I1,...] into separate real/imag registers
        vfloat32m4x2_t vx = __riscv_vlseg2e32_v_f32m4x2(x, vl);
        vfloat32m4x2_t vy = __riscv_vlseg2e32_v_f32m4x2(y, vl);

        vfloat32m4_t xr = __riscv_vget_v_f32m4x2_f32m4(vx, 0);  // x real
        vfloat32m4_t xi = __riscv_vget_v_f32m4x2_f32m4(vx, 1);  // x imaginary
        vfloat32m4_t yr = __riscv_vget_v_f32m4x2_f32m4(vy, 0);  // y real
        vfloat32m4_t yi = __riscv_vget_v_f32m4x2_f32m4(vy, 1);  // y imaginary

        // Real part: ac - bd
        vfloat32m4_t zr = __riscv_vfmul_vv_f32m4(xr, yr, vl);   // ac
        zr = __riscv_vfnmsac_vv_f32m4(zr, xi, yi, vl);          // ac - bd

        // Imaginary part: ad + bc
        vfloat32m4_t zi = __riscv_vfmul_vv_f32m4(xr, yi, vl);   // ad
        zi = __riscv_vfmacc_vv_f32m4(zi, xi, yr, vl);           // ad + bc

        // Re-interleave and store
        vfloat32m4x2_t vz = __riscv_vset_v_f32m4_f32m4x2(
            __riscv_vundefined_f32m4x2(), 0, zr);
        vz = __riscv_vset_v_f32m4_f32m4x2(vz, 1, zi);
        __riscv_vsseg2e32_v_f32m4x2(z, vz, vl);
    }
}

This single function processes hundreds of complex multiplications per loop iteration!

The CMake Configuration

# port.cmake
include_directories(${PORT_DIR})

# Enable RVV in compiler
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -march=rv64gcv -mabi=lp64d")

# Use SMALLFT for FFT (SpeexDSP built-in)
add_definitions(-DUSE_SMALLFT)

# Work around upstream AudioMark missing includes
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-implicit-function-declaration")

set(PORT_SOURCE
    ${PORT_DIR}/th_api.c
)

Building AudioMark

Inside the Docker container:

cd audiomark
mkdir build && cd build

cmake .. \
    -DPORT_DIR=/work/audiomark/ports/riscv \
    -DCMAKE_TOOLCHAIN_FILE=/work/riscv_toolchain.cmake

make -j4

The moment of truth:

$ file audiomark
audiomark: ELF 64-bit LSB executable, UCB RISC-V, RVC, double-float ABI...

It compiled! But would it run?

Milestone 4: The Reality Check — Emulation and Hardware

QEMU Emulation Results

$ qemu-riscv64 -cpu rv64,v=true,vlen=128 -L /opt/riscv/sysroot ./audiomark
Initializing
Memory alloc summary:
 bmf = 14876
 aec = 68100
 anr = 45250
 kws = 8264
Computing run speed
Measuring
Total runtime    : 10.526 seconds
Total iterations : 25 iterations
Score            : 1583.437256 AudioMarks

1,583 AudioMarks under emulation. A 2.5x improvement over my scalar baseline!

But QEMU emulation is slow. The real test would be on actual hardware.

The Hybrid Distribution Strategy

To get hardware testing, I needed to make it easy for volunteers. I adopted a hybrid approach:

1. Static Binary: Self-contained, no dependencies

2. Docker Image: Full toolchain for rebuilding

3. GitHub Release: Easy download with one command

Building the static binary:

cmake .. \
    -DPORT_DIR=/work/audiomark/ports/riscv \
    -DCMAKE_TOOLCHAIN_FILE=/work/riscv_toolchain.cmake \
    -DCMAKE_C_FLAGS="-static -march=rv64gcv -mabi=lp64d" \
    -DCMAKE_EXE_LINKER_FLAGS="-static"

make -j4

$ file audiomark
audiomark: ELF 64-bit LSB executable, UCB RISC-V, RVC, double-float ABI, 
           version 1 (GNU/Linux), statically linked

I created a GitHub Release with the binary attached.

Real Hardware Results — The Moment of Truth

I reached out to sanderjo, who generously offered to test on his SpacemiT hardware. I created a issue in his repo link to the issue - https://github.com/sanderjo/SpacemiT-K3-X100-A100/issues/6

SpacemiT K3 (Banana Pi F3):

superkoning@spacemit:~/eembc-audiomark$ ./audiomark-rvv-static
Initializing
Memory alloc summary:
 bmf = 14876
 aec = 68100
 anr = 45250
 kws = 8264
Computing run speed
Measuring
Total runtime    : 11.011 seconds
Total iterations : 585 iterations
Score            : 35418.703125 AudioMarks

35,418 AudioMarks.

I had to read it twice. That's 22x faster than QEMU emulation!

Sanderjo was so kind he ran it on his old harware too (SpacemiT K1 (X60))

SpacemiT K1 (X60):

sander@bananapif3:~/eembc-audiomark$ ./audiomark-rvv-static
Initializing
Memory alloc summary:
 bmf = 14876
 aec = 68100
 anr = 45250
 kws = 8264
Computing run speed
Measuring
Total runtime    : 10.983 seconds
Total iterations : 208 iterations
Score            : 12625.140625 AudioMarks

12,625 AudioMarks on the older K1 — proving VLEN independence works!

The Final Scorecard

Yayyyyyyyyyyy 641 to 35,418 AudioMarks — a 55x improvement from scalar to optimized hardware!🎉🎉🎉

Resources

• GitHub Repository: Ayushd785/riscv-Audiomark-lab

• Docker Image: docker pull ayushd785/riscv-audio-lab

• Static Binary Release: v0.2-rvv-alpha

• EEMBC AudioMark: github.com/eembc/audiomark

• VOLK RVV Port (Reference): PR #774

Acknowledgments

• Edward Vielmetti — Community guidance and support

• sanderjo — Hardware testing on SpacemiT K1 and K3

• Olaf Bernstein — The VOLK RVV implementation that taught me the patterns

• EEMBC — For creating the AudioMark benchmark

Thanks for reading! If you're working on RISC-V or audio DSP, I'd love to connect.

Author: Ayush Dwivedi
Github: Ayushd785
Mail: ayushd785@gmail.com
Date: 29th January 2026

The target: EEMBC AudioMark — an industry-standard benchmark that simulates a real-world audio pipeline with beamforming, echo cancellation, noise reduction, and keyword spotting. It's the perfect testbed for DSP optimization.

The problem: AudioMark didn't have a ready-to-go Linux/RISC-V port. My laptop runs Fedora on x86_64. I don't own RISC-V hardware. But I need RISC-V code running today.

This post documents the journey from "broken build" to "working benchmark."

This flowchart illustrates the Cross-Compilation Pipeline required when your development machine (x86) is different from your target architecture (RISC-V).

1. It starts with your C Source Code, which cannot run on RISC-V as-is.

2. The Cross-Compiler acts as a "Bridge," translating that code into a machine-readable RISC-V Binary (ELF file).

3. Since your laptop cannot natively run this binary, it is passed to the QEMU Emulator.

4. QEMU translates the RISC-V instructions in real-time, allowing the program to execute on your laptop and establishing "The Proof" that the build works.

The Environment: Setting the Stage

My Setup:

• Host: Fedora Linux (x86_64)

• Goal: Port the AudioMark benchmark to RISC-V

• Reality: I have no physical RISC-V hardware, so I must rely on emulation.

The Native "Sanity Check"

Before diving into the complexities of cross-compilation (where things break easily), I needed to establish a Golden Baseline. I needed to verify that the benchmark logic itself—the beamforming, the neural net, the error checking—worked correctly on my reliable x86 laptop.

1. Install Prerequisites

First, I grabbed the standard build tools from the Fedora repositories:

sudo dnf install git cmake make gcc gcc-c++

2. Clone the Repository

I pulled the official EEMBC AudioMark source code:

git clone https://github.com/eembc/audiomark.git
cd audiomark

3. Configure and Build (The "Reference" Build)

Here is the trick: AudioMark doesn't come with a generic "Linux" port out of the box. However, the ports/arm directory contains a standard C reference implementation that is compatible with x86 GCC.

I compiled it using the host's native compiler:

$ cd audiomark && mkdir build && cd build
$ cmake .. -DPORT_DIR=$HOME/opensource/audiomark/ports/arm
$ make audiomark

4. Run the Benchmark

With the binary built, I executed it locally to see what "success" looks like:

$ ./audiomark

Native Result (x86_64):

Score: ~8275 AudioMarks

This result was crucial. It proved that the code is bug-free. Any errors I encounter later are guaranteed to be caused by my RISC-V porting efforts, not the benchmark itself.

The First Hurdle: The Brain Without a Body

Like any developer, I tried the easy way first:

$ sudo dnf install gcc-riscv64-linux-gnu

Installation succeeded. I had a compiler! I updated my CMake toolchain file, hit build, and...

/opt/riscv/bin/riscv64-unknown-linux-gnu-gcc -c main.c
In file included from main.c:1:
ee_audiomark.h:15:10: fatal error: stdint.h: No such file or directory
   15 | #include <stdint.h>
      |          ^~~~~~~~~~
compilation terminated.

The dreaded "No such file or directory."

I spent nearly 2 hours debugging this. stdint.h is one of the most basic files in C programming. How could a compiler not know what an integer is?

What Went Wrong?

The Fedora package gave me a compiler (the brain), but not a sysroot (the vocabulary).

A sysroot is a directory containing all the standard library headers (stdint.h, stdio.h, string.h) and libraries (libc.so) that your code needs. Without it, the compiler can translate your code into machine instructions, but it doesn't know what printf or malloc mean.

The Fedora package is designed for kernel development (where you don't use libc), not userspace applications like AudioMark.

The Solution: Building the Toolchain from Source

If distributions won't give us a complete toolchain, we build our own. — Yes i felt that kick

The riscv-gnu-toolchain is the official RISC-V compiler infrastructure. It builds GCC, Binutils, GDB, and (crucially) glibc for RISC-V.

Step 1: Install Build Dependencies

$ sudo dnf install -y autoconf automake python3 libmpc-devel mpfr-devel \
    gmp-devel gawk bison flex texinfo patchutils gcc gcc-c++ zlib-devel \
    expat-devel libslirp-devel

Step 2: Clone the Repository

# Create installation directory
$ sudo mkdir -p /opt/riscv
$ sudo chown $USER /opt/riscv

# Configure for Linux userspace (this builds glibc!)
$ ./configure --prefix=/opt/riscv --disable-gdb

# Build (grab coffee, this takes 30-60 minutes)
$ make linux -j$(nproc)

The make linux target is critical — it builds a toolchain for Linux userspace applications with full glibc support. The alternative, make, builds a "bare-metal" toolchain without libc.

Step 4: Verify the Installation

$ ls /opt/riscv/bin/
riscv64-unknown-linux-gnu-gcc
riscv64-unknown-linux-gnu-g++
riscv64-unknown-linux-gnu-ld
...

$ ls /opt/riscv/sysroot/usr/include/
stdint.h  stdio.h  stdlib.h  string.h  ...

We have our sysroot! The missing stdint.h is now at /opt/riscv/sysroot/usr/include/stdint.h.

The Bridge: CMake and Cross-Compilation

CMake defaults to the host compiler. We need to force it to use our RISC-V toolchain. This is done with a toolchain file.

riscv_toolchain.cmake

# Tell CMake we're building for Linux on RISC-V
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR riscv64)

# THE KEY FIX: Point to our sysroot
set(CMAKE_SYSROOT /opt/riscv/sysroot)

# Use our custom compilers
set(CMAKE_C_COMPILER /opt/riscv/bin/riscv64-unknown-linux-gnu-gcc)
set(CMAKE_CXX_COMPILER /opt/riscv/bin/riscv64-unknown-linux-gnu-g++)

# Don't try to run test programs (they're RISC-V, we're x86!)
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)

# Ensure compiler finds sysroot libraries
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} --sysroot=${CMAKE_SYSROOT}")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --sysroot=${CMAKE_SYSROOT}")

The critical line is CMAKE_SYSROOT. This tells CMake and GCC where to find headers and libraries. Without it, we're back to the "brain without a body" problem.

Building with the Toolchain File

$ cd build
$ rm -rf *  # Clean previous x86 build

$ cmake .. -DPORT_DIR=$HOME/opensource/audiomark/ports/arm \
           -DCMAKE_TOOLCHAIN_FILE=../riscv_toolchain.cmake

$ make audiomark -j$(nproc)

This was an Aha! moment for me to be honest!

Let's verify we actually built a RISC-V binary:

$ file audiomark
audiomark: ELF 64-bit LSB executable, UCB RISC-V, RVC, double-float ABI, 
           version 1 (SYSV), dynamically linked, 
           interpreter /lib/ld-linux-riscv64-lp64d.so.1, 
           for GNU/Linux 4.15.0, not stripped

We have a RISC-V executable. But how do we run it on an x86 laptop?

The Climax: Emulation and The Dynamic Linker Crash

Enter QEMU

QEMU is a processor emulator. It can run RISC-V binaries on x86 by translating instructions in real-time.

$ sudo dnf install qemu-user-static

The qemu-riscv64-static binary will execute our RISC-V code. Is it that easy??

$ qemu-riscv64-static ./audiomark

Crash: Obviously no

qemu-riscv64-static: Could not open '/lib/ld-linux-riscv64-lp64d.so.1': 
No such file or directory

The Problem

Our binary needs shared libraries (libc.so, etc.). But it's looking for them in /lib/ — which contains x86 libraries, not RISC-V ones!

QEMU is smart enough to detect the binary is RISC-V, but it still searches default paths for dependencies.

The Fix

We use the -L flag to redirect QEMU to our sysroot:

$ qemu-riscv64-static -L /opt/riscv/sysroot ./audiomark -verbose

Output:

Initializing
Memory alloc summary:
 bmf = 14952
 aec = 68100
 anr = 45250
 kws = 8308
Computing run speed
Measuring
Total runtime    : 10.385 seconds
Total iterations : 10 iterations
Score            : 641.929016 AudioMarks

YAyyyyyyyyyyyy IT WORKED!!! 🎉

Results & Analysis:

Performance Comparison

Interpretation: Why the 12x Slowdown is Actually a Win

At first glance, dropping from ~8275 to ~641 AudioMarks looks like a performance regression. However, this is entirely expected and, in fact, represents a successful port. Here is the technical breakdown of that performance delta:

1. The Cost of Dynamic Binary Translation (DBT)

We are running this binary on QEMU User Mode, which is an emulator, not a virtualizer.

• How it works: QEMU uses a Tiny Code Generator (TCG) to translate RISC-V instructions into x86_64 instructions in real-time.

• The Overhead: Every time the benchmark tries to execute a simple RISC-V fadd.s (floating point add), QEMU has to pause, look up the equivalent x86 machine code, generate it, and then execute it. This adds massive latency to every single cycle.

2. Scalar Bottlenecks (The "One at a Time" Problem)

The current build uses the generic C implementation of the DSP kernels (originally from the ARM port).

• The Math: This code is Scalar, meaning it processes data elements one by one (Single Instruction, Single Data).

• The Consequence: To process a 1024-sample audio buffer, the CPU has to fetch, decode, and execute instructions 1024 times.

• The Future Fix: In Phase 2, we will implement RISC-V Vectors (RVV). This will allow us to process vast chunks of that buffer (e.g., 8 or 16 floats) in a single CPU cycle, drastically reducing the instruction fetch overhead.

3. Functional Correctness > Raw Speed

The most important metric right now isn't the speed (641), but the Score itself.

• AudioMark only generates a score if the output audio passes strict Signal-to-Noise Ratio (SNR) and Distortion thresholds.

• The fact that we got a valid score proves that our cross-compiled math is bit-exact. The floating-point unit (FPU), memory allocation, and pointer arithmetic are all functioning correctly on the RISC-V architecture.

Memory Allocation Breakdown

The benchmark allocates memory for each component:

These values are identical between x86 and RISC-V, confirming the port is functionally correct.

Lessons Learned

1. Distributions Don't Always Have What You Need

The "easy" dnf install gave me a compiler without a sysroot. Sometimes you have to build from source.

2. CMAKE_SYSROOT is Your Best Friend

Cross-compilation breaks in mysterious ways without it. Always set it explicitly in your toolchain file.

3. QEMU Needs Library Paths Too

The -L flag is essential. QEMU won't magically find your sysroot libraries.

4. Emulation ≠ Performance Testing

QEMU proves your code works. It doesn't tell you how fast it'll run on real hardware.

Conclusion: From Broken to Baseline

We went from:

• "fatal error: stdint.h not found"

• "Could not open ld-linux-riscv64"

To:

• A complete RISC-V toolchain at /opt/riscv

• A working CMake cross-compilation setup

• AudioMark running on RISC-V via QEMU

• A baseline score of 641.93 AudioMarks

What's Next: The Sequel

This was Phase 1: Make it work.

Phase 2: Make it fast.

In the next post, I'll implement custom DSP kernels using RISC-V Vector (RVV) intrinsics. Functions like:

• th_add_f32 → vfadd.vv (vector addition)

• th_dot_prod_f32 → vfmacc + reduction

• th_cmplx_mult_cmplx_f32 → Segmented loads + fused multiply-add

The goal: Beat that 641 score by leveraging SIMD parallelism. Stay tuned.

Thanks for reading! If you're working on RISC-V or audio DSP, I'd love to connect.

Author: Ayush Dwivedi
Github: Ayushd785
Mail: ayushd785@gmail.com
Date: January 2026