WaveTable audio Datas and structures on SD ?

Status
Not open for further replies.
B

Baloran

Active member
Hi All,

Would it be completely silly and/or infeasible to transfer the audio and structure data of a wavetable set to an SD . These files could be loaded on demand by the user to the and transferred dynamically in EXTMEM (PSRAM) for example ?
Even if the capacity of Teensy 4.1 is remarkable, the PROGMEM space is limited and the sound bank is frozen at compilation time.
I'm thinking of getting into this project, I would like to have your point of view beforehand.
 
Merci ;)
My idea is a bit different because I'm thinking of making an intermediate appl in which I compile several soundfonts and which will save them as "RAW" data (structure and audio) on SD to avoid having to do a syntax analysis of the CPP and H sources. Indeed the memory space both PROG and MEM is "limited", a simple Mellotron Wave (one sample per octave...) killed my compilation.....
 
Playing large wavetable samples from PSRAM will not produce the desired results at default T4.1 clock of 600 MHz with the current audio library wavetable object. I believe this has to do with the speed of access to PSRAM (80MHz). The only way I have found to play large wavetables (~512k+) is to place them in flash (PROGMEM). You can however call wavetables to the heap from PSRAM provided the total size is less than the available memory. I've found it beneficial to edit my own wavetables to reduce their total size.
 
Last edited:
Thanks RABB17
I have made a test with transfert from PROGMEM to PSRAM. It's work fine with AUDIO_SAMPLE_RATE_EXACT 88200.0f en CPU% and timming is low....


Code: 
// Just for test ;)
EXTMEM nc_instrument_data ex_instrument_data[NB_SF2_PLACE];
EXTMEM nc_sample_data ex_sample_data[NB_SAMPLE_PLACE];
EXTMEM uint32_t ex_audio[100000];

....
for (ct=0;ct<nb_sample;ct++)
{
memcpy( (void *)&ex_sample_data[index_sample+ct] , (void *)smd, sizeof(nc_sample_data) );
...
smd++;
}
...
// Copy audio sample -> EXTMEM 

samples = (uint32_t *)(smd)->sample;
for (uint32_t cpy = 0 ; cpy < nbsamples; cpy++ )   ex_audio[index_audio++] = *(samples++);
....

wavetable.setInstrument( (const AudioSynthWavetable::instrument_data&) ex_instrument_data[0]
 
Transferring between the two shouldn't be an issue, out of curiosity have you tried playing a tone sweep of the wavetable from EXTMEM? The code will compile no problems, but from what I have experienced the wavetable will not be produced faithfully in a very noticeable way.
 
I only tested with flute_100K but I make no difference between EXTMEM and PROGMEM. The goal is still for me to make a memory dump on SD of a collection of PROGMEMs so that the user can select them and reload them on demand to EXTMEM. Voluntarily my tool does not have a big polyphony because I reserve CPU power for other syntheses ;)
 
Baloran said:
I only tested with flute_100K but I make no difference between EXTMEM and PROGMEM. The goal is still for me to make a memory dump on SD of a collection of PROGMEMs so that the user can select them and reload them on demand to EXTMEM. Voluntarily my tool does not have a big polyphony because I reserve CPU power for other syntheses ;)
Click to expand...

I haven't tried files smaller than 512k from EXTMEM, but that is interesting news. I ran some simple code to test larger wavetables (over 1MB) from EXTMEM and the results were not correct. Same tables placed in flash sounded perfect. It would be interesting to see if someone else had managed to play accurate larger wavetables from the PSRAM. Out of curiosity, why move wavetables from PROGMEM to EXTMEM? SD -> PSRAM, sure, but access to the flash is much faster than the psram, maybe I'm missing something?
Are you wanting to modify the wavetables themselves at runtime?
 
I will try to build large wave tables for my tests. I'm watching some SF2 from Mellotron with greed :D I'll keep you informed of the results.
No, I don't propose to modify the wavetables, just that the user can load the sounds that suit his needs and possibly exchange them with other users.
 
Status
Not open for further replies.
Back
Top