Possible to "fake" I2S output using PDM?

[echo-lalia]

I have a funny question, and I'm curious to hear your thoughts!

Im developing a software for a M5Stack Cardputer, which is an Esp32-s3 device, with an I2S speaker built into it. The I2S speaker is really nice for playing back samples and high quality generated signals. However, I'd also like to use it just like a "beeper".

I made a little module for generating a simple square wave to a chosen frequency, and sending it to the I2S output. However, it feels kinda janky and imperfect. It also blocks my code, and it certainly feels needlessly complex for such a simple task. I've used simple buzzers in MicroPython before, and I really like the way they're easy to work with, and they work really well for short, loud tones, for UI feedback.

I'm curious if anyone knows whether or not it's possible to abuse the I2S peripheral a bit, and treat it more like a simple buzzer for this purpose, by generating 2 PWM signals to imitate the clock and word select, and then using a 3rd PWM signal to imitate a data signal flipping from 0x00-0xff.

If course, I'll probably just try it out once I'm back at my PC. But if anyone's tried it before, or sees some issues with my logic here, I'd appreciate your input before I waste my time (or, idk, blow up my speaker 😅)

[miketeachman]

Have you looked at using the non-blocking mode to implement buzzers and beepers? You can create short wav files and send them to the I2S peripheral using the non-blocking mode. There is no need to block. See examples here.

[echo-lalia]

Thank you for the response!

Unfortunately, I have tried using a non-blocking module (M5Sound) made by another person. It works really well for high quality audio playback, but for UI feedback specifically, it just doesn't seem to respond fast enough.

I've looked through quite a few I2S examples in my quest to get this working, however, they mainly seem to focus on playing back wav files, and stuff like that. And I think I'd run into the same issue. The sound needs to be perceptually instant, or else it feels wrong.

Of course, it could just be that I'm missing some way of making the sound play faster; perhaps I just need to explore the topic further. I had kinda just written off the non-blocking mode as being poorly suited for what I'm doing, especially when most of the tones I'm trying to play are short enough to cause the "blocking" to be nearly imperceptible.

[miketeachman]

Are you reading the wav files from media (flash file system or SD card) every time the sound is played? If so, this will create a delay. A suggestion is to preload the audio samples into a byte array to eliminate the delay of reading from media.

[miketeachman]

@echo-lalia
Here is some code for the ESP32 demonstrating how to get a fast audio response after a trigger event, using the I2S non-blocking mode. In this case I found that it takes about 7.7ms from a trigger event to the first audio sample being transmitted on the I2S bus. I did the timing measurement with an oscilloscope, using a digital output to mimic a trigger event. There are two key design points that enable this fast response:

• inserting a delay right after instantiating the I2S object. This delay allows the internal buffer, 10000 bytes in this example, to be flushed out by DMA.
• preloading the sample data into memory

The beep.wav file used in this example is 5338 bytes in length. I used a Lolin D32 Pro development board which has an ESP32 WROVER module. Hopefully the ESP32-S3 has a similar response.

Would 7.7ms be perceived as a fast enough response for a user?

import os
import time
import micropython
from machine import I2S
from machine import Pin
from machine import SDCard

sd = SDCard(slot=2, sck=18, mosi=23, miso=19, cs=4)
os.mount(sd, "/sd")

# ======= I2S CONFIGURATION =======
SCK_PIN = 33
WS_PIN =25
SD_PIN = 32
I2S_ID = 1
BUFFER_LENGTH_IN_BYTES = 10000
# ======= I2S CONFIGURATION =======

# ======= AUDIO CONFIGURATION =======
WAV_FILE = "beep.wav"
WAV_SAMPLE_SIZE_IN_BITS = 16
FORMAT = I2S.MONO
SAMPLE_RATE_IN_HZ = 11025
# ======= AUDIO CONFIGURATION =======

def i2s_callback(arg):
    print("cb")

scope_sync = Pin(21, Pin.OUT, value=0)

audio_out = I2S(
    I2S_ID,
    sck=Pin(SCK_PIN),
    ws=Pin(WS_PIN),
    sd=Pin(SD_PIN),
    mode=I2S.TX,
    bits=WAV_SAMPLE_SIZE_IN_BITS,
    format=FORMAT,
    rate=SAMPLE_RATE_IN_HZ,
    ibuf=BUFFER_LENGTH_IN_BYTES,
)

audio_out.irq(i2s_callback)

wav = open("/sd/{}".format(WAV_FILE), "rb")
_ = wav.seek(44)  # advance to first byte of Data section in WAV file

# allocate sample array buffer
wav_samples = bytearray(10000)
wav_samples_mv = memoryview(wav_samples)

# time delay to allow internal Tx buffer to be emptied by DMA
time.sleep(1)

# preload samples into application buffer
num_read = wav.readinto(wav_samples_mv)
print('num_read', num_read)

# toggle IO.  This simulates a pushbutton or some trigger in the application program
scope_sync.value(1)
_ = audio_out.write(wav_samples_mv[:num_read])
scope_sync.value(0)

print('done')

Here is an oscilloscope capture showing the signals SCK, WS, SD, DIO sync (top to bottom). The delay from DIO going high to the first audio sample on the I2S bus is about 7.7ms.

[echo-lalia]

Thank you so much for this super detailed response!

I'm sorry I haven't responded sooner; I've been preoccupied and I was trying to avoid pinging you until I had experimented more.

The program I'm developing is designed to be a platform for community-made apps. I think I may be struggling because my samples are too short.

The ui-tones module I want to build for it needs to use as little memory as possible, be capable of running standalone (as a plain .py file), and be capable of being frozen into micropython.

So my tests have been using very short wave samples stored as constants in the .py file, and repeated many times. I assume this is what's causing my problems, unfortunately.

I'm not certain, but I think the reason could be that the wave is shorter than the I2S buffer, so it plays silence before starting the ui tone.