Inquiry Regarding ReSpeaker Lite Voice Assistant Kit

I purchased the ReSpeaker Lite Voice Assistant Kit.
I plan to connect it to Debian 12 and run voice tests.
I would like to ask the following questions:

  1. On GitHub, I found the following firmware files:

    • respeaker_lite_i2s_dfu_firmware_48k_v1.1.0_ch0-asr_ch1-mww.bin

    • respeaker_lite_i2s_factory_firmware_v1.1.0_ch0-asr_ch1-mww.bin
      Are USB versions of these firmware files available?

  2. Is there a way to control the kit via USB, similar to the I2S version?
    If so, could you provide an example?

  3. The file respeaker_lite_v1.0_sch_1.pdf seems to lack sufficient details.
    Is a more complete or detailed schematic available?

  4. The XMOS XU316 XMS0001-SCHEMATIC-1V0-A.pdf appears to be a development board.
    Are there any differences between this design and the ReSpeaker Lite circuit?

  5. If I build the XMOS XU316 SDK without modifications and update the firmware via DFU,
    will I encounter any issues when using it on the ReSpeaker Lite?

Please provide answers to questions 1 through 5 above.

Hi there,

And Welcome here…

So you’ll want to READ the WiKi on the product as most of the Answers you are asking are there. It would also be very beneficial to search here on the forum for some as well lots of topics pertaining to it exists. :+1:

1). Do you mean Flash Files? Typically on the Wiki are links.
2). I2S is the Sound Quality ? You can use a USB supported WIN version or Use it with an I2S pre-amp or DAC
3). In the end of each product WiKi is a resource section, Schematics and needed files are there, along with links for other support items.
4). You will need to compare them to be sure. SOme new versions and New firmware has been released.
5). NOt sure what you mean, perhaps another person will chime in , but it the targets are different it won’t work.

HTH
GL :santa_claus: PJ :christmas_tree:

I am currently testing the board connected to an Orange Pi CM5.
At the moment, I am controlling it through USB, but it appears that the I2S firmware provides the ability to control registers via I²C. I need to confirm whether this feature is available when using the USB firmware.

Additionally, when using the XU316 manufacturer SDK, it seems that building and flashing the default board firmware may cause issues. I need guidance on how to resolve this problem.

1 Like

Hi there,

So I took a look this morning and as you know those two firmware images:

  • respeaker_lite_i2s_dfu_firmware_48k_v1.1.0_ch0-asr_ch1-mww.bin
  • respeaker_lite_i2s_factory_firmware_v1.1.0_ch0-asr_ch1-mww.bin

are XMOS firmware builds configured for I²S audio output,
not USB Audio Class devices.

  • The XU316 absolutely supports USB Audio, but Seeed did not ship a USB-Audio firmware image for ReSpeaker Lite.

  • What they shipped is firmware where the XU316 acts as a DSP + audio front end, pushing audio out via I²S to a host SoC (Pi, ESP32, etc.). :backhand_index_pointing_left: :laughing:

  • There is no prebuilt “USB mic” firmware from Seeed for ReSpeaker Lite.

  • You would need to build your own USB Audio firmware using the XMOS SDK.

This is a deliberate design choice, not an omission. #1 is a NO

Number two , #2 is a similar situation, The silicon can but only if you build custom firmware. :face_with_peeking_eye: Out of the box:

  • USB is used for power, flashing (DFU), and debug
  • It is not exposed as a USB Audio Class device

However, the XU316 is fully capable of:

  • USB Audio Class 2.0 (UAC2)
  • USB control endpoints
  • Vendor-specific USB commands

It’s not Turnkey but it is possible to code it.

  • Install the XMOS XTC tools + XU316 SDK
  • Start from an XMOS USB Audio reference design
  • Adapt it to:
  • ReSpeaker Lite mic array
  • Correct PDM microphone mapping
  • Existing DSP chain (ASR / MWW if desired)

Also, it is an embedded firmware task, not a Linux config task so an effort would be required to bring it to fruition but not undoable. :+1:

There is no official “example” from Seeed because they intentionally positioned this board as an I²S voice front end, not a USB peripheral.
I’m with you on the Schematic, but pretty normal though for this class of product. The PDF is a functional schematic, not a full manufacturing or reference design.

What’s missing (intentionally):

  • Exact impedance tuning
  • Internal XMOS reference routing details
  • Some power-domain subtleties
  • Test-point annotations

This is typical:

  • Seeed does not publish full production schematics for most commercial kits
  • What you get is enough to understand signal flow, not clone the board

If someone expects Altium-grade production files, they’re barking up the wrong tree.
The Xiao family is different, You get the full monty. :v: :grin:
The XMOS XU316 Dev board and ReSpeaker Lite You can’t assume drop-in compatability, there are significant differences between the two boards too.
The dev board is more of a learning tool or platform, the ReSpkr. Lite is a productized design I think it’s also like REV 2 or 3 of the product?

You can’t flash stock builds without changes i.e if you build an unmodified XMOS USB or I2S and flash it by DFU, you will have issues on a couple spots;

  • Mic channels mapped incorrectly
  • No audio output
  • Clocking mismatch
  • USB enumerates but no audio streams
  • DSP pipeline not initialized

the reason is the SDK examples target XMOS reference hardware

  • ReSpeaker Lite has custom pin mappings and mic topology

you need to:

  • Modify the board support config
  • Adjust mic channel assignments
  • Verify clock source assumptions
  • Possibly tune FIR/AEC stages

This is expected for XMOS-based products. There is no free lunch, they are a teach a man to fish kinda joint. thin on examples :sweat_smile:

AI , puts it this way:

If I had to say this plainly to the user:

  • ReSpeaker Lite is not a USB microphone by default
  • It is an I²S voice front end with an XMOS DSP
  • USB Audio is possible, but you must build it
  • The schematics are intentionally partial
  • The XMOS dev board is not electrically equivalent
  • Flashing stock firmware will not just work

This isn’t a beginner board — it’s a professional voice front end that assumes the user knows embedded audio.

If that matches their expectations, they’re on the right hardware. If not, they may want a simpler USB mic array instead.

That’s the honest answer.

HTH

GL :santa_claus: PJ :christmas_tree:

Then, I built a custom baseboard using an RK3588 CM board. I understood this to mean that I can connect and use I2S and I2C on it.

So, if I connect I2S, can I assume that the system will receive audio through the default I2S interface, and for I2C, I can control it in Python by referring to the ESP32 examples on GitHub and configuring the XU316 registers?

Or, when receiving audio via I2S, is there any special control or driver required?

1 Like

Hi there,

So I have Not built it before, but I believe that is the case with the I2S audio, and I don’t see why the Python controlled I2C shouldn’t work when I look at the setup in whole.

Probably will work good like that, if the code is efficient. timing is Tight :+1:

HTH
GL :santa_claus: PJ :v:

The Usr button wiki seems to suggest that the USB functionality will be added at some time in the future but it’s been quite a long time since a firmware was released. The V2 hat seems to have dropped recently. Is there a chance that Seeed will actually release a USB firmware that supports the HID LED and Button? Based on the changelogs the XU316 is wired to the LED which means both the LED and Usr button support should be possible.

1 Like

@PJ_Glasso - thanks so much for your post and this thread. Just received the same reSpeaker Lit boards (qty 2) for R&D and testing on Windows 10/11 platforms.

Appears under Other Devices → yellow marked reSpeaker Lite function. Error Code 28.

Should I be seeing the attached enumeration message of this USB board?

From 2 different host PCs and 2 different reSpeaker Lite boards.

What are we missing? Expected the boards to be PnP enumerated using Windows native USB audio drivers. We are wanting to test the far field audio pickup and stream the contents over I2S to the ESP32S3 for some testing. Initially was curious on using an USB microphone.

So we need to install the XMOS toolchain? Noting this, we will need to apply the proper GPIO pins for the microphones as applied by Seeed vs. the XMOS evkits. Are these details public on the GPIO pin mappings?

Hi there,

Thnx,
So I think most of these XU316 devices have this driver anomaly on install. sometimes using Zadig to get WinUSB attached so they can verify the board state with dfu-util -l or re-flash the correct binary.

Because Windows is throwing an Error Code 28 (missing/uninstalled driver) under Other Devices, the native Windows USB Audio 2.0 driver isn’t binding correctly—or the XMOS XU316 is stuck in a boot/DFU state that Windows doesn’t inherently map to a generic plug-and-play sound card.

  • For Flashing/DFU: If mon2 needs to use dfu-util to flash either the USB firmware or the I2S firmware to match their ESP32S3 setup, the official Seeed Studio ReSpeaker Lite Wiki explicitly instructs using Zadig to install the WinUSB driver over the device (often listed as DFU FACTORY or ReSpeaker Lite on Interface 3) to allow the libusb-based dfu-util toolchain to communicate with it.
  • For standard PnP Audio: If you just want it to behave like a standard plug-and-play USB microphone/sound card, Windows should ideally handle it natively if it has the default USB firmware loaded. However, if it’s currently bricked, missing firmware, or loaded with the raw I2S firmware, Windows will choke.

check if it is stuck in DFU mode. most likely :+1:

HTH
GL :slight_smile: PJ :v:

Thanks for your reply. Got this working yesterday. The kit was not ready to use out of the box. We did have to apply the DFU tool after using Zadig and then the USB firmware to allow us to test with Audacity. This worked well. Have yet to test the same over I2S but did perform the I2S diags using Arduino and they passed.

The Seeed article notes that this kit should appear as a USB audio device and is ready to use. It was not. Was yellow marked and under Other Devices. Have emailed their tech support but no reply as of this writing.

How deep are you into the XMOS firmware toolchain? Would you know if the most recent AI capable IP is compatible with this hardware? Did Seeed use the same GPIO pins on the XU316 for the mics and I2S output as XMOS? Moving further, can we apply the firmware from XMOS onto this hardware for testing or is there an encrypted bootloader from Seeed?

Hi there,

So, I’m Glad :sweat_smile: you got the board talking and un-bricked via Zadig and dfu-util yesterday! That initial yellow-triangle roadblock on Windows is a classic XMOS introduction. (been there)

To answer your specific hardware and toolchain questions:

1. Pinout & GPIO Compatibility

Seeed’s hardware implementation differs noticeably from standard XMOS reference designs (like the XK-VOICE-L71 or Nabu Casa / Home Assistant Pipeline Editions):

  • Duplex I2S Mapping: The standard XMOS reference firmware typically routes audio over two completely independent, half-duplex I2S channels (separate sets of BCLK/LRCLK lines) to allow the mics to operate strictly at 16 kHz while the speaker plays at 48kHz.
  • The Seeed Route: To keep things compatible with the ultra-low pin count of the XIAO form factor, Seeed routed the ReSpeaker Lite as a single, full-duplex I2S interface sharing one set of clocks (BCLK, LRCLK, DIN, DOUT). Because it’s pinned out this way, you are tied to a single, locked sample rate in both directions (either 16kHz or 48 kHz globally depending on which Seeed firmware binary you flash).

Because of this specific physical tracing, flashing an off-the-shelf, multi-clock reference binary from the XMOS toolchain will result in a mismatch—the clocks and pins simply won’t line up with how the hardware is physically routed.

2. Flashing Custom XMOS Firmware & Bootloader Encryption

You can write and flash your own custom firmware built via the XMOS toolchain, but with a few caveats:

  • No Encryption Lock: Seeed does not explicitly encrypt the bootloader to lock out third-party code; you can access the raw XU316 JTAG debug pads on the bottom of the board or flash custom binaries via the dfu-util loop.
  • The Proprietary Algorithm Catch: While you can compile vanilla XMOS code, the specialized DSP / Voice Audio Front-End (VAFE) algorithms running on the ReSpeaker Lite—specifically the blind interference cancellation (IC), Acoustic Echo Cancellation (AEC), and noise suppression—are part of a proprietary firmware build package provided by Seeed and XMOS. If you completely wipe the flash with a standard baseline XMOS app, you lose that pre-baked front-end tuning unless you meticulously rebuild the DSP pipeline in your own app.

3. Most Recent AI-Capable IP Compatibility

The XU316 is fully capable of running localized, low-latency machine learning tasks (like custom keyword/wake-word spotting or simple intent classification vector math). However, if you are looking to pull down the newest baseline xcore.ai IP or heavily optimized neural network models directly from XMOS GitHub repos, you will run into an immediate roadblock with the full-duplex I2S constraint mentioned above.

To make it work, you would need to fork the open-source portions of the XMOS firmware codebase, manually alter the pin map and I2S configuration files to force the full-duplex single-clock configuration, and then compile your custom target binary. The Juice isn’t worth the squeeze IMHO :crossed_fingers:

Are you looking to use the XU316 to run custom local vector models, or are you hoping to adapt a specific open-source voice-kit firmware to it?

They are like the Nvidia clone boards are just off enough to be a PITA if you don’t know your way around, or follow directions for flashing, etc. Unfortunately a clone is harder in the speaker because the hardware was and ESP32 based, the New nRF54L20A would be a better version IMO.

It has a big following to in the discord. FYI.

HTH
GL :slight_smile: PJ :v: