Playing multiple WAV files at the same time - SD settings

alrj

Well-known member
Hello all!

On T4 I am looking for a way to play multiple wav or stereo raw files at the same time. The T4 using SDIO can happily play (8!!!) stereo wav files at the same time but if you launch them all at the same time you get drop out on the first one (the wave form has gaps in it when recorded and reviewed) this only happens for the first fractions of a second then it all works perfectly again.

This is using the wav player example with the wav player duplicated. The RAW player is mono only which isn't ideal as all my files are stereo.

In the note on the audio config tool it says to un-comment the SD optimisation when playing multiple files, if I do this on T4 then it wont compile. are these optimisations still relevant to T4 and SDIO as I know SDIO is much faster anyway.

I have tried staggering the loading of each wav slightly using a counter but for some reason this actually causes more drop outs and clicks when loading every file rather than just the first one...

Code:
  int currentWAVloadMS = millis();
  int prevWAVloadMS = millis();
  int durWAVload = 10;
  int LOADtime = 1;
  int index = 1;

  while (LOADtime == 1) {

    currentWAVloadMS = millis();
    
  if (currentWAVloadMS - prevWAVloadMS >= durWAVload) {

  // Start playing the files
  if (index == 1) { playSdWav1.play(filename1); Serial.println("Debug"); }
  if (index == 2) { playSdWav2.play(filename2); Serial.println("Debug"); }
  if (index == 3) { playSdWav3.play(filename3); Serial.println("Debug"); }
  if (index == 4) { playSdWav4.play(filename4); Serial.println("Debug"); }
  if (index == 5) { playSdWav5.play(filename5); Serial.println("Debug"); }
  if (index == 6) { playSdWav6.play(filename6); Serial.println("Debug"); }
  if (index == 7) { playSdWav7.play(filename7); Serial.println("Debug"); }
  if (index == 8) { playSdWav8.play(filename8); Serial.println("Debug"); }
  if (index == 9) { LOADtime = 0; }

   prevWAVloadMS = currentWAVloadMS;
   index++;

  }
  }

I know I am asking a lot from the T4 but the fact that it plays all the audio fine once the files are loaded makes me think there must be a way to load them In a way which doesn't cause dropouts.

Is there a way to increase the buffer used when loading to give the system a bit more headroom?

Thanks all, -A
 
I still get some pops and clicks just loading 4 stereo wav files at the same time, which you would of thought would be okay. there must be an optimisation I can do? the issue is present using SPI and SDIO although you can play 8 stereo wavs with SDIO and a max of 6 with SPI.

edit: its only the initial loading of the wavs where you get clicks. once they are playing it all works perfectly.

cranking AudioMemory up doesn't make any difference, I am 90% sure its to do with reading off the SD card.

A
 
Last edited:
In the image top is the file playing as the other 2 or 3 wav files load, below is what it looks like while playing if a load is not happening

Screen Shot 2020-05-20 at 10.40.12.jpg

edit: this is loading 4 wavs at the same time after stopping the previous 4, with SDIO using SD.h on T4.0
 
If I have two playing and trigger another 4 in a cycle I also get a click...

Screen Shot 2020-05-20 at 11.52.46.png

but they all play together fine once they are up and running. : / I tried with RAW files but got the same issue, plus the RAW are mono so it ruins the stereo field when they are not triggered exactly together.
 
It really sounds like #define USE_TEENSY3_OPTIMIZED_CODE would fix my issue but even just on the wavplayer example on T4 it wont compile...

Code:
/Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/card_t3.cpp:31:29: error: conflicting declaration 'volatile uint8_t* SDClass::csreg'
 volatile uint8_t * SDClass::csreg;
                             ^
In file included from /Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/card_t3.cpp:28:0:
/Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/SD_t3.h:85:32: note: previous declaration as 'volatile unsigned int* SDClass::csreg'
  static volatile IO_REG_TYPE * csreg;
                                ^
/Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/card_t3.cpp:31:29: warning: declaration of 'volatile unsigned int* SDClass::csreg' outside of class is not definition [-fpermissive]
 volatile uint8_t * SDClass::csreg;
                             ^
/Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/card_t3.cpp:32:18: error: conflicting declaration 'uint8_t SDClass::csmask'
 uint8_t SDClass::csmask;
                  ^
In file included from /Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/card_t3.cpp:28:0:
/Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/SD_t3.h:86:21: note: previous declaration as 'unsigned int SDClass::csmask'
  static IO_REG_TYPE csmask;
                     ^
/Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/card_t3.cpp:32:18: warning: declaration of 'unsigned int SDClass::csmask' outside of class is not definition [-fpermissive]
 uint8_t SDClass::csmask;
                  ^
/Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/card_t3.cpp: In static member function 'static bool SDClass::sd_read(uint32_t, void*)':
/Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/card_t3.cpp:113:2: error: 'SPI0_PUSHR' was not declared in this scope
  SPI0_PUSHR = 0xFFFF | SPI_PUSHR_CTAS(1);
  ^
/Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/card_t3.cpp:113:40: error: 'SPI_PUSHR_CTAS' was not declared in this scope
  SPI0_PUSHR = 0xFFFF | SPI_PUSHR_CTAS(1);
                                        ^
/Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/card_t3.cpp:116:12: error: 'SPI0_SR' was not declared in this scope
   while (!(SPI0_SR & 0xF0)) ;
            ^
/Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/card_t3.cpp:118:17: error: 'SPI0_POPR' was not declared in this scope
   uint32_t in = SPI0_POPR;
                 ^
/Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/card_t3.cpp:122:11: error: 'SPI0_SR' was not declared in this scope
  while (!(SPI0_SR & 0xF0)) ;
           ^
/Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/card_t3.cpp:123:16: error: 'SPI0_POPR' was not declared in this scope
  uint32_t in = SPI0_POPR;
                ^
/Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/card_t3.cpp:126:11: error: 'SPI0_SR' was not declared in this scope
  while (!(SPI0_SR & 0xF0)) ;
           ^
/Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/init_t3.cpp: In function 'uint32_t unaligned_read32_align16(const void*)':
/Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/init_t3.cpp:44:55: warning: pointer of type 'void *' used in arithmetic [-Wpointer-arith]
  return *(const uint16_t *)p | (*(const uint16_t *)(p+1) << 16);
                                                       ^
/Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/init_t3.cpp: In function 'uint32_t unaligned_read16_align8(const void*)':
/Applications/Ard Teensyduino.app/Contents/Java/hardware/teensy/avr/libraries/SD/init_t3.cpp:53:53: warning: pointer of type 'void *' used in arithmetic [-Wpointer-arith]
  return *(const uint8_t *)p | (*(const uint8_t *)(p+1) << 8);
 
Hello! Unfortunately I have ran into similar issues trying to get the optimized code to run in lieu of the standard Arduino code. I've brought it up a couple times and people have tried to help but I think at this point there is no answer out there for this particular issue when it comes to specifically working with the T4 because surely if there was i'd have gotten an answer on it by now. Even though most everyone on here is here out of the kindness of their hearts, I find most of the time if there is an answer out there it DOES seem to get bandied about at some point. Hey by the way, good luck with 8! Feel like it took re-inventing the Wheel, Spam, and sliced bread just to get 2 tiny clips to play in sync. Did get it though! Seems like an overflow issue would be what's knocking out the voice you mention and simply increasing the memory you have allocated to the AudioMemory would likely eliminate at least the overflow. Honestly though that could all be nonsense I just thought i'd throw it in there since i was on here checking out the amazing Teensy Timer Tool that has saved my life. Good luck and God speed!
 
Thanks for the reply Newton!

I since abandoned trying to get 8 working at the same time, I have 4x Teensy 4.0 networked using serial and they trigger 2 tracks each. I have put well over 2 weeks into trying to cure the problem with no joy but I do understand it very well now :(

If I was a more experienced programmer I would have certainly got to the root of the issue quicker, I have certainly learnt a lot along the way.

Basically the issued is caused by SD.h, which cant read random data fast at all. this means when you load a new track with one already playing this bit of code in the wav player causes the whole system to wait and you get drop out as a result while SD.h does its thing:

Code:
__disable_irq();
wavfile = SD.open(filename);
__enable_irq();

I had a real kick in the teeth yesterday when I thought I had it all working and went from about 50 test files in the root of each SD card to the 1000 I need for the system to operate. At this point I realised some of the files that were put on the card last take even longer for SD.h to find and the issue has resurfaced even with just two wav players on each Teensy.

A friend of mine who is a more experienced programmer has offered to take a look but he doesn't have any time at the moment, so I am trying to get to the bottom of it myself.

I got some great answers on this thread: https://forum.pjrc.com/threads/61072-Is-there-a-way-to-increase-the-audio-lib-buffer
And I found that the new SDfat beta half solves the issue but then causes hangs if you trigger the wavs quickly: https://forum.pjrc.com/threads/57669-SdFat-SDIO-for-Teensy-4-0?p=241181&viewfull=1#post241181
 
I hope this isn't un-PC here to say this, but if you need 8 tracks, stereo, and 1000 files and are trying to network 4 teensies to do the job, wouldn't you simply be better off with a pi4? Then you can run a full OS and tools like fluidsynth to build sound from any interface you may build. In this case, the teensy4 would rock as an i/o processor for knobs and high quality audio output from the pi.
 
Ta for the message, I can't code in python and really don't want an os running so pi is out of the running.

The SD issues are present even if you only have two wav players so I am sure it will get sorted at some point. I have tried to fix it but I have not been able too. I have a less than ideal temporary solution which is to divide the wavs out so only the ones that are need are present on the SD for each Teensy, this means the fat table stays quick enough for the audio needed for 15/20 tunes which is my current set and then some.

Edit, same link as in my post above the answers in this thread explain the issue much better: https://forum.pjrc.com/threads/61072-Is-there-a-way-to-increase-the-audio-lib-buffer
When I created this thread I still wasn't sure what was going on but its all pretty clear now.
 
Hey hey! Yeah I originally got a pi 4 to resolve my issues, which at the time had more to do with the seamlessness of the loops during playback than the one outlined by alrj earlier. However, I must admit I myself had the exact same response once I saw the solution in action. The whole reason I started teaching myself the EE required to design this device instead of merely purchasing a smaller hardware/software version of a traditional DJ setup was because I didn't want a whole OS running in the background either, definitely not just to play a couple of loops i'd recorded previously in various combinations.

Ironically, because of a new Timing issue i'm running into - I'm actually BACK to trying out stuff on the pi 4 to see if maybe i can get what i'm looking for there haha.

Boxxofrobots, your comment actually made me think of something i hadn't even considered before, combining the pi4 with the teensy! thanks for that inspiration, maybe I could use the teensy strictly for the transport module. Seems like something you've actually put together before, do you have anything posted where you use the teensy for the i/o processor as mentioned before? if not no worries and as always thank you all for the chat. Happy teensy tinkering!
 
Hey hey! Yeah I originally got a pi 4 to resolve my issues, which at the time had more to do with the seamlessness of the loops during playback than the one outlined by alrj earlier. However, I must admit I myself had the exact same response once I saw the solution in action. The whole reason I started teaching myself the EE required to design this device instead of merely purchasing a smaller hardware/software version of a traditional DJ setup was because I didn't want a whole OS running in the background either, definitely not just to play a couple of loops i'd recorded previously in various combinations.

Ironically, because of a new Timing issue i'm running into - I'm actually BACK to trying out stuff on the pi 4 to see if maybe i can get what i'm looking for there haha.

Boxxofrobots, your comment actually made me think of something i hadn't even considered before, combining the pi4 with the teensy! thanks for that inspiration, maybe I could use the teensy strictly for the transport module. Seems like something you've actually put together before, do you have anything posted where you use the teensy for the i/o processor as mentioned before? if not no worries and as always thank you all for the chat. Happy teensy tinkering!

I've been experimenting with the Teensy since, I believe, T2 or so? Rpi I only had zeroes and a 3, but an 8GB pi4 is one of my next planned purchases. The teensy can do USB audio out and midi i/o, so yeah it does make better fit for the pi than buying one of the pi audio shields. I'm working on several things at once that are all synths, but of different types and purpose. What I'm building in the meantime is a "toybox" where I can have a self contained transport of spare parts, USB charged battery, 32 knobs and a primitive keyboard and room inside for that pi4 when I get it. My goal is to control synth patches on the pi via those previously mentioned usb ports and programming on the teensy. So far, it's just been my ubuntu workstation.

front.jpg20200531_201742.jpg
 
I've been experimenting with the Teensy since, I believe, T2 or so? Rpi I only had zeroes and a 3, but an 8GB pi4 is one of my next planned purchases. The teensy can do USB audio out and midi i/o, so yeah it does make better fit for the pi than buying one of the pi audio shields. I'm working on several things at once that are all synths, but of different types and purpose. What I'm building in the meantime is a "toybox" where I can have a self contained transport of spare parts, USB charged battery, 32 knobs and a primitive keyboard and room inside for that pi4 when I get it. My goal is to control synth patches on the pi via those previously mentioned usb ports and programming on the teensy. So far, it's just been my ubuntu workstation.

View attachment 20397View attachment 20398

Hey hey that's glorious looking! Also extremely helpful insights, as the whole thing I was really waiting on to give my Pi 4 solution a real 'try' is the atrocious sound quality you get from just using it as is or plugging into one of the few audio interfaces I have (which are really clunky and require too much setup/breakdown anyway). I was at the breaking point and honestly based on your prior comments I had decided to just give in, break down and buy the audio shield. Even that decision would be crazy since there are other purposes for that particular device I'll need to keep in mind like usability with kali linux. made worse by the fact I wouldn't know if the whole thing is better or not until buying it so who knows I could get it, then realize it's just about the same or that the music software doesn't play with the security stuff well. Now I can have my cake and eat it too if I can basically use the teensy in lieu of the shield. that's amazing. Let me ask you this if it isn't too weird simply chatting on this, what do you mean a 'self contained transport'? - i'm getting the impression its basically a 'main console' you can portably lug around much easier than a full on workstation - but it would also house all of the patch configurations you'd need for the various synths plus maybe some additional adaptors or random firmware components for same-correct? That's awesome if so. Portability is the entire thing that brought me into this world and I will gladly proclaim that the teensy has blown away the other solutions I tried at the beginning like the mega 2560 and the wavtrigger which had decent looping logic baked into it. With what sounds like a decent range of variety in synthesis you obviously require for your projects i'm surprised to hear you aren't building out your oscillators and all the sound generation tech via the T!
 
Ta for the replies gents. Cool looking kit boxxofrobots. If possible it would be good to keep this thread on topic. I really have no interest in running linux, and the SD issue with the T4 seems fixable and fairly serious.

NewtonBIV as a temporary work around I have found that a single Teensy 4.0 can play 2 stereo wav files and if you "delay(5);" just before re-tiggering both players at the same time, so long as you have less than 500 wavs on the SD card it all works as it should. (its not true seamless playback but there are no nasty artefacts) Obviously the T4 is capable of much much more than this but the current SD.h lib is holding it back. I have been triggering the T4s using serial, here is a couple of pics...

1.jpg

2.jpg

https://photos.app.goo.gl/rpHvsoQe4LVXHFLn8

The other bit of hardware in the picture is a Sparkfun Tsunami Wav trigger which allows playback of up to 18 stereo wav files at 44.1k, on 8 outputs! There is a seamless loop option per wav file and you can also pitch the samples + and - an octave so I am using this as a sampler until the T4 can take its place. The Tsunami firmware is not open source but it has a Arduino control lib that is. I have this running on the 5th Teensy with midi control via usb host.

Regards, Al.
 
Ta for the replies gents. Cool looking kit boxxofrobots. If possible it would be good to keep this thread on topic. I really have no interest in running linux, and the SD issue with the T4 seems fixable and fairly serious.

NewtonBIV as a temporary work around I have found that a single Teensy 4.0 can play 2 stereo wav files and if you "delay(5);" just before re-tiggering both players at the same time, so long as you have less than 500 wavs on the SD card it all works as it should. (its not true seamless playback but there are no nasty artefacts) Obviously the T4 is capable of much much more than this but the current SD.h lib is holding it back. I have been triggering the T4s using serial, here is a couple of pics...

View attachment 20401

View attachment 20402

https://photos.app.goo.gl/rpHvsoQe4LVXHFLn8

The other bit of hardware in the picture is a Sparkfun Tsunami Wav trigger which allows playback of up to 18 stereo wav files at 44.1k, on 8 outputs! There is a seamless loop option per wav file and you can also pitch the samples + and - an octave so I am using this as a sampler until the T4 can take its place. The Tsunami firmware is not open source but it has a Arduino control lib that is. I have this running on the 5th Teensy with midi control via usb host.

Regards, Al.

Hello Al! Sure thing and apologies of course. Yes that Tsunami has been sooooo incredibly tempting due to the fact it basically promises all of the things i'm looking for in one package. Too bad you have to basically take out a second mortgage to get one! The thing is pricey is my point haha. That's actually really interesting it can go a whole octave in each direction. I really like your code up there too, surprised you didn't go with a switch case but regardless it still appears fairly streamlined for having so many distinct objects playing. So are you needing to pitch up or down your samples? That's an attribute I know has reared it's ugly low-pitched head on here a few times. Closest I was ever able to get was through using different sampling rates and throwing a raw file into a wav player or vice versa (total accident but it was playing the file at half speed so i experimented with a bunch of different combos). Would love to hear how your setup turned out especially with the combo of the teensy & Robertsonic's Tsunami!
 
The Teensy 4.1 with a pair of audio shields should be able to perform the same as the Tsunami, but the libraries need time to catch up to the new capabilities. If you don't need 4 stereo outputs, then when it comes right down to it a teensy 4.1 alone should be able to do everything the Sparkfun board does, albeit with a bit lower audio quality direct from pins 10 and 12.

I'm hoping the soundfont libraries will get updated, too, to allow use of SD storage of sound fonts with full capabilities for several voices at once. The new Teensy is a real baller.
 
Ta for the input both : ) The code in my original post actually didn't work in the end so I would avoid that. I have spent today setting up a Teensy to work with the Tsunami and provide a legato glide like function and it is awesome. The Tsunami will probably be kept on even once the SD.h issues are fixed on the Teensy simply because the +/- 1 octave pitch bend sounds and works great. its also pretty easy to set up attack and release settings using the Arduino control lib. I am playing resampled bass so there is only ever one voice running at a time and its like silk... ultra low latency. I wish the SD.h lib hadn't defeated me but I put so much time into it. Looking forward to someone who knows their stuff being able to sort it.

edit; note on your post above boxxofrobots, the Tsunami has 4 stereo (or 8 mono) outputs on the board. This is possible with the Teensy using either TDM or the newly added octa I2S out with 4x DACs
 
I just want to make sure that you'd considered soldering on a flash memory chip? That's how I'm attempting to solve my similar problem, althoughI still haven't been able to get it to work. From what I heard, data retrieval from the chip is blindingly fast compared to an SD card.

I'm using the PJRC audio shield, which has a hand spot to solder it on, so it might not work for this project. And, as I say, I've been bashing my head against it for most of a month now and still dno't have it working. But I'm close, I can feel it! And certainly plenty of other folks have.
 
Haha wow it doesn't look like any of my prior responses came up on here. I know that one specifically went to someone directly by accident but the others I believe went to another dimension. I listened to the BABS series by the way. Now I understand the need for so many voices! That's what you are doing right? Putting a series of oscilators overtop each other, maybe running some kind of a filter through an LFO or may daisychaining an envelope to a compressor? There is some sort of glitch technicque in there I remember from back in my day in Miami that I can't put my finger on but it sure doesn't sound like an FM or anything out of the box.

Ok thank you all for the excellent suggestions, Dionysus have you gotten the flash to work yet and seen it in action? I'm following the number of folks going in that direction on here and simply waiting for someone to do it and post how they did and then more than likely i'm going to get a flash for sure. as of now I hadn't even tried the application someone put up here for easy transfer but I guess there is no point in trying it until I get the flash. Only thing is I need 5 GB as well, they don't have anything on the market for flash memory that has that much memory on it?? If so than goodness I saw this.
 
Thought you guys might be interested in this post.... https://github.com/greiman/SdFat-beta/issues/51#issuecomment-646184476

It seems Bill doesn't have any interest in developing SDfat further which is a shame but fair enough he has made a huge contribution to the community already.

As it looks like we are stuck with the current performance limitations of the old SD.h until Paul looks into it (I am not sure what priority he considers the issue to be) I might have to look into using a pi for my system even though its more or less running with several Teensys.
 
NewtonBIV—yep! it was a huge pain, with a ton of hardware problems followed by a ton of software problems, but ultimately everything is playing nicely!

The key coding thing for me was being very careful about including the libraries and the initilization code for all the SPI hardware. I'm using the touchscreen, a display, an SD card, and the flash chip, but when I was testing it, I'd plug everything together but then try to run code for just the flash chip, and there would be hella conflicts. So, for example, I had to modify RawHardwareTest so that it also has the line "SD.begin(SDCARD_CS_PIN)", even though the rest of the program doesn't care about the SD card at all.

I'm also following someone clever's advice (probably defragster?) and explicitly disabling SPI access for everything else when accessing the flash chip. I mean, I don't think this is supposed to be necessary, and it might just be superstition, but my function to load samples onto the flash chip beings with:

Code:
  pinMode(SDCARD_CS_PIN, OUTPUT);
  digitalWrite(SDCARD_CS_PIN, HIGH);  
  pinMode(TFT_CS, OUTPUT);                        // Make sure the screen doesn't try to access SPI while we're using it
  digitalWrite(TFT_CS, HIGH);  
  pinMode(TS_CS, OUTPUT);                         // Also make sure the touch interface doesn't mess with our SPI access
  digitalWrite(TS_CS, HIGH);  
  delay(1);

To signal that the SD reader, the touchscreen, and the display should not be accessing SPI. Anyway, if anyone is interested, I'm happy to send you code my code—it writes to the display, reads touch input, reads a file from the SDcard, and writes that file to the flash chip. I could also send you code that does a whole bunch more than that, but it got so messy that I couldn't even edit it anymore so I started over from ground zero. :)
 
Hi Teensy folks,

I'm experiencing the same issue trying to read multiple wave files simultaneously, and I'm considering 2 alternatives to overcome the problems that seemed caused by the SD library.
Let's say I want to play 8 mono files (44khz / 16 bit) together. I'm using the Teensy 4.0.

1/ Implement a thread that populates some buffers (stored in ram or most probably flash) for each of the files to read from. This way the files would be read at once every x ms rather than concurrently using multiple AudioPlaySdWav objects.
Then create a new audio object similar to AudioPlayMemory that would read from the buffers instead.

2/ Create an 8 channel interleaved wave file from my 8 mono files, and implement a new audio object with 8 outputs for each of the channels. This way the SD library only has one file to deal with and there shouldn't be any conflicts.

I'd rather go with option 1 since it seems less hassle, however I'm not convinced it will resolve the issue.

Any ideas or suggestions before I embark on the journey?

Thanks!

Ben
 
Last edited:
Hi Teensy folks,

I'm experiencing the same issue trying to read multiple wave files simultaneously, and I'm considering 2 alternatives to overcome the problems that seemed caused by the SD library.
Let's say I want to play 8 mono files (44khz / 16 bit) together. I'm using the Teensy 4.0.

1/ Implement a thread that populates some buffers (stored in ram or most probably flash) for each of the files to read from. This way the files would be read at once every x ms rather than concurrently using multiple AudioPlaySdWav objects.
Then create a new audio object similar to AudioPlayMemory that would read from the buffers instead.

2/ Create an 8 channel interleaved wave file from my 8 mono files, and implement a new audio object with 8 outputs for each of the channels. This way the SD library only has one file to deal with and there shouldn't be any conflicts.

I'd rather go with option 1 since it seems less hassle, however I'm not convinced it will resolve the issue.

Any ideas or suggestions before I embark on the journey?

Thanks!

Ben

Hi Ben!

Did you ever go on with your plans of creating a flash/ram buffer for AudioPlaySdWav?

-Miro
 
Back
Top