Best Method for Fast Playing of Samples with 8-voice Polyphony?

Hi again,

Even just declaring a second AudioPlayWav object in the second program above causes the file to sometimes not be played completely.

Adding, for example,
Code:
AudioPlayWav           playSdWavs[32];
to that code, but without doing anything else with those objects, causes significant delays when playing (although each plays to the end). This shows some output for that case - the wav file is 20 ms long, and there's a delay(30) after each play.

Version3.jpg

All the best,

Alan
 
Thank you! Can you upload the file please?
If fixed some things yesterday. Do you use the newest version?
 
Files for testing

Thanks Frank,

The attached folder has a 20 ms clip and a 1 s clip.
I was using the version of your library from the 28th. It may be a few days before I can try the latest version,

All the best,

Alan
 

Attachments

  • WAV_files.zip
    46.8 KB · Views: 36
Ok, my changes seem to have fixed the issue.

The other issue, with the delay at end is.. hm, i did not think of this.. or..better.. did not think of this effect as a problem :)
The player works in a way, that the memory for all players grows the more players exist. This is needed for the "Interleaved reads" Paul wanted.
At the end of each file, it adds zero-samples.. If there is much allocated memory (many players), there will be many zero samples at the end... hm
I think I know how to fix it..
 
Ha! When I recorded over a longer time check if the "added too much zeroes" issue from above was fixed, i finally saw the problem at start. It does not happen often, perhaps 1 of 20 times?
2022-02-02 20_26_02-Window.png
But it should look like that:
2022-02-02 20_26_33-Window.png

But... I have absolutely no idea why this happens (and what??)... if you look closer, the shorter file is indeed playing - you see a glitch during the first 8 sines. But what happens...??
 
IF it was playing, the amplitude should be higher, like in picture #2. But it IS playing, because you see 2 glitches in the first sines (exactly the length of the shorter file)).

Any Idea?

The shorter file alone (with the longer disabled) plays every time...
 
Looks like the two sines are canceling out each other.. so it's timing..
indeed if I rewrite the loop to :
Code:
  [B]AudioNoInterrupts();[/B]
  for (int i = 0; i<2; i++)
  {
    playSdWav[i].pause(false);
  }
[B]  AudioInterrupts();[/B]
...it does not happen.

Problem solved? I hope..
 
Hi Frank,

I'll check the updated library as soon as I can. Playing two equals sine waves does mean that they sometimes cancel out - but it makes variations in latency very clear, and it's possible to measure delays very easily (by just measuring the amplitude of the combined signal).

All the best,

Alan
 
Take your time, no hurry.

It was never meant to be that "exact".. it's just a dumb player. But if it is possible.. why not.
I like the idea of the sines.. did not think of them as an instrument to measure things in connection with the player. Thank you!

For EOF, please keep in mind that there still will be 0..AUDIO_BLOCK_SIZE-1 zero samples. The exact number is not predictable - it depends on the number of played files, the exact start time, and last, the number of samples in the file.
(A "gapless" sound would need the loop feature - but it's untested in this regard)
 
This might not at all be applicable or needed but if you want to make your life more difficult which is a skill I excel in, you could save the first let's say 100ms of samples (or some other number of milliseconds of samples) in internal memory so you have the time to get the rest of the sample from a slower memory(SD Card)
You would off course then need to get the rest of the sample from a file but it least it will "buy" you some time.
I also looked at the OPUS which is touted as a low latency encoding (22.5ms) but I suspect it has a lot lower latency decoding for which I could not find any information. For starters you can just compress your samples and see if you can make them fit in faster SPI memory before you do any programming.
You would need to get a hold of a OPUS (or other audio compression format) which might just make it fit in faster memory. You can get an opus or other already supported audio decoder and see if you run all your samples through that on Linux/Apple/Mac and see how much they compress and if you can make it fit.
I have to be honest and did not do the math on all of this but I had the idea and decided to share. I can remove this post if it is counterproductive or not useful. I would like to thank you all for discussing this problem in this forum since some of the problems and suggested solutions make for a fascinating read.
 
I measured the time for open() a file from SD (aif in this case). It's around 0.5..2.5 ms most of the time. Sometimes (seldom) a little more.
But yes, fast SPI filesystem would be better. Unfortunately, LittleFS often needs 10x the time.
 
wooohooo Frank B replied to one of my posts. I really hope this did not take you from working on more important and more wonderful work you are doing on the Teensy platform. I really want to thank you for all your work on the Teensy and I've been reading a lot of your work and libraries and I'm trying to get it all to work for my little looper project but I really have to learn a lot and I don't understand a lot yet. My post really just is solving a problem that is not there but I've not seen anyone talking about compressing audio samples in the smaller system memory and maybe for certain applications that would mean you don't have to deal with putting your samples in slower memory.
I also thought it is probably way more work but if you could put like 88 samples in one file and only do like 100ms slices so you don't have to access 88 individual files and put them in internal memory and swap them out so you can play maybe way more than 14 sample files. I would not know for a use case but I had the idea and I decided to share.
 
Back
Top