Rp2040 port: using I2s(0) and I2S(1) in parallel

[Flipje1955]

with two seperate HW set-ups (gpio pins, max98357 DAC, speaker), would it technically possble to use the 1st available i2s for playing wav-files (read from an sdcard) whilst using the 2nd available i2s to create an occasional "sound_over" ? These would be typical say 5 sec bursts (which I would store in flash memory possibly triggering me to use a Rp2040's with 16M flash).

Mike Teachman has created some very nice examples (thx a lot !), inclusive an asyncio version that might support what I am looking for. Not having any experience with asyncio, it might not enable feeding both streams without running into buffer underflows. I expect - but might miss other crucial matters - that will be the crictical part.
Sound quality is not critical, so I could go for low sampling rates, mono.

The use case behind this is: I develop hw/sw to operate a miniature railway track and plan to dedicate a RP2040 for producing diesel / steam loc sounds, There is plenty of material on youtube so I can create a "library" of authentic sounds for the various loc's that I have and model them to the loc's operation (start/stop...). The sound_over's are the literally the "whistles and bells" that I can schedule or have called at random.

Using Mike's examples I got the first stream to work; now the next step. Thx for sharing any thoughts / advice.

Rob

[miketeachman]

Hi Rob,
What a cool application of MicroPython. I think your proposal will work. This is a perfect use of asyncio (most MicroPython applications benefit from asyncio). I think it's a worthwhile investment of your time to learn asyncio.

To get started, here is an approach to consider, adapting the asyncio example in the repo.

• instantiate two I2S instances, audio_out_continuous and audio_out_random. On all MicroPython ports, I2S instances are mostly independent. The processing of audio samples by one I2S instance will have very little affect on the processing of audio sample by a second instance.
• create two asyncio tasks.

1. The first task would implement the continuous railway sounds, using a coroutine named continuous_play() and the audio_out_continuous I2S instance.
2. The second task would call a second coroutine that might be called random_play() This second coroutine would look much like the first coroutine except you will want the main loop to wait on an event before creating the sound. The sound samples will be directed to the audio_out_random I2S instance. To start simple, you might consider implementing a continuous loop that plays a short sound, then waits for say 5 seconds (using the function uasyncio.sleep). As you suggested, the sound can be pre-loaded into a bytearray, assuming you have enough memory. After that is working, you can change the loop to play the sound on-demand, by waiting on an asyncio event where the asyncio event is set with an asyncio pushbutton class. e.g. set the asyncio event in the press_func method.

This is just one approach. I would see if @peterhinch can review your use case and comment. He's the preeminent MicroPython asyncio application expert.

As an aside, I've considered creating an I2S PR, to add a static mixer method to the I2S class that would allow multiple sample streams to be mixed together. Having a mixer method would eliminate the need for two sets of I2S DAC hardware. The mixer method would be implemented in C to be fast. A MicroPython based `mixer' implementation is possible, but it might be too slow for some higher sample rates (or maybe even lower sample rates).

Hope this helps. Please report on your progress.

[obdevel]

As an aside, I've considered creating an I2S PR, to add a static mixer method to the I2S class that would allow multiple sample streams to be mixed together. Having a mixer method would eliminate the need for two sets of I2S DAC hardware. The mixer method would be implemented in C to be fast. A MicroPython based `mixer' implementation is possible, but it might be too slow for some higher sample rates (or maybe even lower sample rates).

I'd be very interested to see this happen, and would be happy to test.

I've experimented with this (in Arduino) using 3rd party RP2040 boards (with a 16MB flash chip rather than SD) and both Phil Schatzmann's and Earle Philhower's libraries.

An ideal mixer would handle new audio streams joining the mix as well as completed streams leaving. Looping of streams would be nice to have too.

Whilst MP3 decoding would be nice too, it would haul a lot of code into the UF2 binary. WAV is fine with larger flash chips.

Thanks.

[peterhinch]

I think this should be feasible with suitable buffering. You might like to look at this demo which is a player for audio files, notably this section which aims to reduce allocation. In this application buffering is necessary because reading from SD cards is slow. The DMA from the buffer proceeds in the backgound and enables continuous audio output.

[Flipje1955]

Mike / Peter, thank you for both the guidance and your quick responses. Let me take a first dive into asyncio to appreciate its wow in order to engage prepared in this more serious material. Good to hear that you believe the approach is feasable.
Will keep you informed.

[peterhinch]

Let me take a first dive into asyncio

See uasyncio tutorial.