Trying to get an RP2040 USB audio to i2s working.

[sniperzero22]

Hi,

Firstly thank you for all your hard work on this port and Arduino audio tools.

I am trying to get working a RP2040 to be a simple USB interface and transfer audio via i2s to a DAC. Eventually to get a working usb wifi audio transmitter to a receiving end. I have the receiving end working with Arduino Audio tools Vban->i2s with an esp32s3 and the same DAC listed below. It is working using the Voicemeter software to send out the vban stream. However I am looking to get it via usb for the transmitter rather than requiring Voicemeter.

Hardware I am using:

The RP2040 board - https://www.aliexpress.com/item/1005007650325892.html
DAC - https://www.aliexpress.com/item/1005007477490325.html
The DAC has the serial jumper soldered and on the back is bridge as all LOW except H3L bridged HIGH.

Pin config:
bck = 29;
ws = 28;
data = 14;
gnd = gnd
vin = 3v3

Wiring:

The code:

#include <Arduino.h>
#include "Adafruit_TinyUSB.h"
#include "AudioTools.h" 

Adafruit_USBD_Audio usb;
I2SStream out; 
size_t sample_count = 0;

size_t writeCB(const uint8_t* data, size_t len, Adafruit_USBD_Audio& ref) {

  /*
  Serial.print(" WRITING:  ");
  Serial.print(len);
  Serial.print(" - ");
  Serial.println((char *)data);
  */

  out.write(data, len);

  size_t samples = len / sizeof(int16_t);
  sample_count += samples;

  return len;
}

void setup() {

  if (!TinyUSBDevice.isInitialized()) {
    TinyUSBDevice.begin(0);
  }

  Serial.begin(115200);

  AudioLogger::instance().begin(Serial, AudioLogger::Warning); 

  auto config_out = out.defaultConfig(TX_MODE);
  config_out.i2s_format = I2S_PHILIPS_FORMAT;
  config_out.is_master = false; 
  config_out.pin_bck = 29;
  config_out.pin_ws = 28;
  config_out.pin_data = 14;
  config_out.sample_rate = 44100; 
  config_out.channels = 2;
  config_out.bits_per_sample = 16;
  
  out.begin(config_out);

  usb.setWriteCallback(writeCB);
  usb.begin(44100,2,16);

  if (TinyUSBDevice.mounted()) {
    TinyUSBDevice.detach();
    delay(10);
    TinyUSBDevice.attach();
  }

}

void loop() {

  if (usb.updateLED()){
    Serial.print("Total samples: ");
    Serial.print(sample_count);
    Serial.print(" / Sample rate: ");
    Serial.println(usb.rate());
  }

}

Platformio config:

[env:pico]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
board = pico
framework = arduino
board_build.core = earlephilhower
build_flags =  -DUSE_TINYUSB -DTUD_OPT_RHPORT

lib_deps=   https://github.com/pschatzmann/Adafruit_TinyUSB_Arduino.git#Audio
            https://github.com/pschatzmann/arduino-audio-tools

upload_port = E:

Problem I am having:
I get about 2 seconds of clear audio then a sharp loud tone for a few seconds then just stops and it appears the RP2040 locks up. Restarting the RP2040 it will then get clear audio for 2 or so seconds then same issue again.

I tried just the usb side by just outputting the data directly to serial instead of i2s the data gets sent and doesn't appear to lock up. So thinking it might be an i2s issue I tried both a generator example and mp3 (from memory) to i2s (from Arduino audio tools). Both played as expected with clear audio and didn't lock up. The i2s side of the configuration was left identical to when it was using the usb as the input.

I thought maybe it was an issue with the wiring so I changed around to different pins and tried some jumper cables instead of the breadboard. This didn't appear to make any difference at all.

I tried playing around with different sample rate/channel/bit configs as well but didn't appear to make any difference. Something I did notice is if I set the sample rate to 48000 (running on windows 11) it doesn't seem to pick up that its 48000 as per the sound settings window. Set to 44100 however, it does show up.

So I am at a loss on what to try next. I am not a super good programmer and more so a webdev rather than more complex c/c++ code. If ideally the code should work maybe there is an issue with the RP2040 I have. If so I'll try ordering some different variants of them and try with those.

If there is anything you can think of to try I would greatly appreciate it.

Thanks,

Have a great day!

[frohro]

I would like to know if it will work at 48 kHz too. Thank you for testing this for me. I hope this can be made to work in the future.

[h5n1xp]

I have also been testing @pschatzmann's branch to implement the Audio Class.

I can get the RaspberryPi to send audio to the computer without issue, but when the computer sends audio data to the RaspberryPi it only works for a few seconds.

I will try and find some time to see if I can understand what's happening and report back here.

Is this issue related to the bug already posted here? I'll test later.

#2

[sniperzero22]

I can get the RaspberryPi to send audio to the computer without issue, but when the computer sends audio data to the RaspberryPi it only works for a few seconds.

Something I did notice is when using just the windows sound setting (without selecting the pi as the device) I can press the test button that just does a left sound and right channel sound. I can do this pretty much indefinitely and the sound comes through to the pi and over i2s to the output without any issues. However as soon as I select the PI as the device for windows to use or if I select the device in an audio program to use the device. The PI just goes for a second and then locks up.

[h5n1xp]

Interesting, I don't have a Windows machine to test this myself... But I'll assume that the test application is probably sending much smaller packets, and flushing the buffers after each test.

[h5n1xp]

Ok, It seems the TinyUSB is reporting spurious sample rates back to the computer during playback!

Playback was fine until about 20 seconds when the computer flagged and issue with the device suddenly reporting that it was using 45,801Hz rather than 44,100 that I had configured.

-Edit- Ok, I was using 4 channels... with only 2 channels the device seems stable. Could I be hitting a bandwidth issue? I have dedicated a core to running the tusb task?

Even with 2 channels there is definitely some synchronisation issues.

I'm trying to build a VUmeter visualiser so I need more than 2 channels.

[pschatzmann]

Since you did not comment out the Serial.print in the loop(): what does the log say ?

[sniperzero22]

Hi,

Ok so if I set it as the device in windows this is how the log is

19:02:15:755 -> Total samples: 0 / Sample rate: 44100
19:02:15:755 -> Total samples: 0 / Sample rate: 44100
19:02:17:374 ->     Get Volume of channel: 1 <--this is when i have selected in windows to use the device as the sound output
19:02:17:376 ->     Get Mute of channel: 1
19:02:17:379 ->     Get Volume of channel: 1
19:02:17:381 ->     Get Mute of channel: 1
19:02:17:391 -> Clock set current freq: 44100
19:02:18:757 -> Total samples: 30964 / Sample rate: 44100
19:02:18:757 -> Total samples: 120638 / Sample rate: 44100
Locked up from here until reset.

If I just use the windows test button in the sound control panel and don't set it as the device. It just plays a ping in left channel and then right channel. This is the log. I pressed the test button 3 times. This I can do over and over and can hear the sound no problems.

19:08:19:984 -> Total samples: 0 / Sample rate: 44100
19:08:19:984 -> Total samples: 0 / Sample rate: 44100
19:08:23:985 -> Total samples: 0 / Sample rate: 44100
19:08:23:985 -> Total samples: 0 / Sample rate: 44100
19:08:27:195 -> Total samples: 0 / Sample rate: 44100
19:08:27:195 ->     Get Volume of channel: 1
19:08:27:197 ->     Get Mute of channel: 1
19:08:27:199 ->     Get Volume of channel: 1
19:08:27:202 ->     Get Mute of channel: 1
19:08:27:213 -> Clock set current freq: 44100
19:08:28:354 -> Total samples: 68230 / Sample rate: 44100
19:08:28:354 -> Clock set current freq: 44100
19:08:29:989 -> Total samples: 155364 / Sample rate: 44100
19:08:29:989 -> Total samples: 232048 / Sample rate: 44100
19:08:33:991 -> Total samples: 232048 / Sample rate: 44100
19:08:33:991 -> Total samples: 232048 / Sample rate: 44100
19:08:36:196 -> Total samples: 232048 / Sample rate: 44100
19:08:36:196 ->     Get Volume of channel: 1
19:08:36:198 ->     Get Mute of channel: 1
19:08:36:201 ->     Get Volume of channel: 1
19:08:36:202 ->     Get Mute of channel: 1
19:08:36:213 -> Clock set current freq: 44100
19:08:37:345 -> Clock set current freq: 44100
19:08:38:994 -> Total samples: 387948 / Sample rate: 44100
19:08:38:994 -> Total samples: 463916 / Sample rate: 44100
19:08:42:996 -> Total samples: 463916 / Sample rate: 44100
19:08:42:996 -> Total samples: 463916 / Sample rate: 44100
19:08:43:504 ->     Get Volume of channel: 1
19:08:43:506 ->     Get Mute of channel: 1
19:08:43:509 ->     Get Volume of channel: 1
19:08:43:511 ->     Get Mute of channel: 1
19:08:43:522 -> Clock set current freq: 44100
19:08:44:666 -> Clock set current freq: 44100
19:08:45:998 -> Total samples: 592494 / Sample rate: 44100
19:08:45:998 -> Total samples: 682168 / Sample rate: 44100
19:08:49:000 -> Total samples: 697218 / Sample rate: 44100
19:08:49:000 -> Total samples: 697218 / Sample rate: 44100

I just got my pico 2w in the mail so I am going to try it as well later tonight.

[pschatzmann]

I needed to extend the AudioTools a bit to provide some RP2040 concurrency classes: I am writing the data into a queue and process it in the loop to output the i2s. I haven't connected a DAC yet but the this implementation is not blocking any more:

#include "Adafruit_TinyUSB.h"
#include "AudioTools.h"
#include "AudioTools/Concurrency/RP2040.h"

AudioInfo info(44100, 2, 16);
Adafruit_USBD_Audio usb;
BufferRP2040 buffer(1024, 10);  // Multi-core and IRQ safe queue 
QueueStream queue(buffer); // Stream API for queue
I2SStream i2s; // i2s output
StreamCopy copier(i2s, queue);

size_t writeCB(const uint8_t* data, size_t len, Adafruit_USBD_Audio& ref) {
  return queue.write(data, len); // fill the queue with data from USB
}

void setup() {  
  Serial.begin(115200);
  AudioToolsLogger.begin(Serial, AudioToolsLogLevel::Info);
  while(!Serial);  // wait for serial
  Serial.println("starting...");
  // start queue
  queue.begin();

  // start i2s
  auto cfg = i2s.defaultConfig(TX_MODE);
  cfg.copyFrom(info);
  i2s.begin(cfg);

  // Start USB device as Audio Sink
  usb.setWriteCallback(writeCB);
  usb.begin(info.sample_rate, info.channels, info.bits_per_sample);

  // If already enumerated, additional class driverr begin() e.g msc, hid, midi won't take effect until re-enumeration
  if (TinyUSBDevice.mounted()) {
    TinyUSBDevice.detach();
    delay(10);
    TinyUSBDevice.attach();
  }
}

void loop() {
  usb.updateLED();
  copier.copy();
}

If the quality is not good, change the log level from Info to Warning

[pschatzmann]

OOps, I think I was a bit too quick: it's still blocking...

[pschatzmann]

I think I have made some progress now: it is not locking up any more at the playback: the key was to move the i2s ougpug to the other core:

#include "Adafruit_TinyUSB.h"
#include "AudioTools.h"
#include "AudioTools/Concurrency/RP2040.h"

AudioInfo info(44100, 2, 16);
Adafruit_USBD_Audio usb;
BufferRP2040 buffer(1024, 10); 
QueueStream queue(buffer);
I2SStream i2s;
StreamCopy copier(i2s, queue);

size_t writeCB(const uint8_t* data, size_t len, Adafruit_USBD_Audio& ref) {
  return queue.write(data, len);
}

void setup() {  
  Serial.begin(115200);
  AudioToolsLogger.begin(Serial, AudioToolsLogLevel::Info);
  //while(!Serial);  // wait for serial
  delay(1000);
  Serial.println("starting...");
  // start queue
  queue.begin();

  //start i2s
  auto cfg = i2s.defaultConfig(TX_MODE);
  cfg.copyFrom(info);
  if (!i2s.begin(cfg)){
    Serial.print("i2s error");
  }

  // Start USB device as Audio Sink
  usb.setWriteCallback(writeCB);
  if (!usb.begin(info.sample_rate, info.channels, info.bits_per_sample)){
    Serial.println("USB error");
  }

  // If already enumerated, additional class driverr begin() e.g msc, hid, midi won't take effect until re-enumeration
  if (TinyUSBDevice.mounted()) {
    TinyUSBDevice.detach();
    delay(10);
    TinyUSBDevice.attach();
  }
}

void loop() {
  usb.updateLED();
}

void loop1() {
  copier.copy();
}

[pschatzmann]

Today I finally managed to connect a DAC to double check. A couple of additional comments

• With log level Info it seems to still lock up: so set it to Warning
• I got the impression that the Project Rate in Audacity must match with the defined sample rate in the Sketch
• I think that I am hearing some underflows: this still needs some more investigation...

[h5n1xp]

I'm getting buffer under-runs.

I put a GPIO pin write in to the writeCB() function, and on a scope can confirm the function is called approximately every 1ms, that suggests the packets sent are too small to cover the audio period of 1ms... I still can't get serial to work but I'm guessing the len value passed to the callback is too small?

[h5n1xp]

Ok, I've noticed that the writeCB() function is called about 100 times (every 1ms), then there is gap of 250ms where it isn't called, then another block of 100 calls. Why is there a 250ms gap in the USB packet transmission every 100ms?

[pschatzmann]

This is internally managed by the tinyusb audio functionality and I am not sure yet how to influence this.
I am currently using AUDIO_FEEDBACK_METHOD_FIFO_COUNT

[h5n1xp]

Ok, well I'll continue hacking around with my local copy of the USB Stack, but I have no idea what I'm doing with USB. I will report back whatever I find.

[pschatzmann]

I added some manual feedback support which takes the buffer fill status into consideration. This is working now w/o any under or overruns:

#include "Adafruit_TinyUSB.h"
#include "AudioTools.h"
#include "AudioTools/Concurrency/RP2040.h"

AudioInfo info(44100, 2, 16);
Adafruit_USBD_Audio usb;
BufferRP2040 buffer(256, 20); 
QueueStream queue(buffer);
I2SStream i2s;
StreamCopy copier(i2s, queue);

size_t writeCB(const uint8_t* data, size_t len, Adafruit_USBD_Audio& ref) {
  usb.setFeedbackPercent(buffer.size()*100 / buffer.available());
  return queue.write(data, len);
}

void setup() {  
  Serial.begin(115200);
  AudioToolsLogger.begin(Serial, AudioToolsLogLevel::Warning);
  while(!Serial);  // wait for serial
  Serial.println("starting...");

  // start queue
  queue.begin(80);

  // Start USB device as Audio Sink
  usb.setFeedbackMethod(AUDIO_FEEDBACK_METHOD_DISABLED);
  usb.setWriteCallback(writeCB);
  if (!usb.begin(info.sample_rate, info.channels, info.bits_per_sample)){
    Serial.println("USB error");
  }

  // If already enumerated, additional class driverr begin() e.g msc, hid, midi won't take effect until re-enumeration
  if (TinyUSBDevice.mounted()) {
    TinyUSBDevice.detach();
    delay(10);
    TinyUSBDevice.attach();
  }
}

void loop() {
  usb.updateLED();
}

void setup1(){
  //start i2s
  auto cfg = i2s.defaultConfig(TX_MODE);
  cfg.copyFrom(info);
  cfg.buffer_size = 256;
  cfg.buffer_count = 3;
  if (!i2s.begin(cfg)){
    Serial.print("i2s error");
  }
}

void loop1() {
  copier.copy();
}

[h5n1xp]

That's fixed the buffer under-runs!!

[sniperzero22]

I added some manual feedback support which takes the buffer fill status into consideration. This is working now w/o any under or overruns:

Thanks for the code update but it seems to introduce distortion into the audio. The only change to the your code above was that I added

  cfg.i2s_format = I2S_PHILIPS_FORMAT;
  cfg.is_master = false; 
  cfg.pin_bck = 21;
  cfg.pin_ws = 20;
  cfg.pin_data = 19;

For the i2s device, I tried this both on the rp2040 and the pico2w both seem to have the audio channels reversed and there is a weird distortion that happens.

I used this video [ https://www.youtube.com/watch?v=YwNs1Z0qRY0 ] as the reference and recorded audio from earbuds to my phone. So quality isn't great but you can hear the distortion in it. Github doesn't seem to let me upload mp3s so i'll just do a super low quality mp4.

20250112.204113.mp4

When running the test sound in windows I do get this distortion as well that wasn't present prior to the new buffering method. I did a fresh update of both libraries as well. I have only had a chance to try if this on windows not a linux based system to see if that might be the issue.

[pschatzmann]

If usb.setFeedbackMethod(AUDIO_FEEDBACK_METHOD_DISABLED); doesn't work for you, then just don't use it!
You can also play around with the buffer sizes

[h5n1xp]

In my code I'm using:

usb.setFeedbackMethod(AUDIO_FEEDBACK_METHOD_FREQUENCY_FIXED);

Which seems to eliminate buffer drift on my test system, but I made some other changes, so I can't confirm that the feedback method AUDIO_FEEDBACK_METHOD_DISABLED was specifically causing problems, but it's worth trying the different methods.

[sniperzero22]

Ok so I have had some luck messing around with my issue. I modified the buffer amounts like crazy (both the i2s and rp2040buffer) but nothing would get even close to sounding right. So I went back to without the buffer (directly i2s.write) but with the feedback settings and it seemed to solve the issue. I think the buffer idea is better though just for the sake of being able to then manipulate/changing different streams easier.

Below the first track (440) is just a sine wave. Audio 1 and 2 tracks were messing around with the buffer but as you can see there is gaps and then strange dips. (Going to be honest I am not an audiophile so I really don't know what I am looking at) However the 4th track is with the code below. which appears to be working "mostly" (I still have weird issue where my left/right channels seem to be reversed however ) flawlessly (fingers crossed). (I tested in both the RP2040 and the PICO 2w)

As I don't really know how to use Audacity I was going to try and see if I could find a way to compare 2 audio tracks. Just to see if there was anything that hiccups that I can't notice when listening.

The only issue I am having is a pop/crack when doing things like skipping ahead/pausing/playing. I am guessing I would have to have some sort of check if there is no audio to prevent it going out to i2s.

Code that seems to be working.

#include "Adafruit_TinyUSB.h"
#include "AudioTools.h"

AudioInfo info(48000, 2, 16);
Adafruit_USBD_Audio usb;
I2SStream i2s;

size_t writeCB(const uint8_t* data, size_t len, Adafruit_USBD_Audio& ref) {
  usb.setFeedbackPercent( 50 ); //Just went for the middle haven't played with other values yet
  return i2s.write(data, len);
}

void setup() {  
  Serial.begin(115200);
  AudioToolsLogger.begin(Serial, AudioToolsLogLevel::Warning);
  Serial.println("starting...");


  auto cfg = i2s.defaultConfig(TX_MODE);
  cfg.copyFrom(info);

  cfg.i2s_format = I2S_PHILIPS_FORMAT;
  cfg.is_master = false; 
  cfg.pin_bck = 29;
  cfg.pin_ws = 28;
  cfg.pin_data = 27;

  if (!i2s.begin(cfg)){
    Serial.print("i2s error");
  }

  usb.setFeedbackMethod(AUDIO_FEEDBACK_METHOD_DISABLED);
  usb.setWriteCallback(writeCB);
  if (!usb.begin(info.sample_rate, info.channels, info.bits_per_sample)){
    Serial.println("USB error");
  }

  // If already enumerated, additional class driverr begin() e.g msc, hid, midi won't take effect until re-enumeration
  if (TinyUSBDevice.mounted()) {
    TinyUSBDevice.detach();
    delay(10);
    TinyUSBDevice.attach();
  }
}

void loop() {
  usb.updateLED();
}

[romain145]

Could we use the DMA to feed the I2S?
https://github.com/earlephilhower/arduino-pico/blob/master/libraries/rp2040/examples/DMAMemcpy/DMAMemcpy.ino

[pschatzmann]

I don't know: why don't you just try it yourself: But consider that i2s is also using the DMA with the PIO....