Hi everyone!
Just a very quick question about the Daisy Seed’s audio buffer. I’ve been working on a project for a while now, and despite the claims from the Seed datasheet, the length of the Audio Buffer seems to be constrained to 14,400,000 samples (5 mins at 48K, which is the MAX_SIZE in the looper example for petal). It would stand to reason that a 10 minute audio buffer would be doable at 24K, but that sample rate doesn’t seem to appear in the AudioClass.h
enum DaisyDuinoSampleRate {
AUDIO_SR_8K,
AUDIO_SR_16K,
AUDIO_SR_32K,
AUDIO_SR_48K,
AUDIO_SR_96K,
AUDIO_SR_LAST,
};
This isn’t really causing me any issue at the moment, I’m just looking for a bit more information of the capability (max size) of the Seed’s audio buffer. If anyone can additionally clarify how to calculate the buffer size from the purported 64MB SDRAM, that would also be fantastic!
Cheers,
-Oliver
‘10 minute audio buffer’ is an exaggeration, a miscalculation, or an error, at 48K sample rate.
.
Your math was correct. The wording is vague probably because it’s intended to answer a very vague question like “how much audio can it store?” that is often asked without clarifying which format is used for that audio.
You can end up with >10 minutes of high quality audio data at 48KHz if it’s stored as 16bit integers. In fact, that’s the reasonable thing to do if it’s read from a WAV file with that format - storing it as 32 bit float would double buffer size which might end up even being slower as you’ll also be reading twice as much data from SDRAM.
When you’re capturing audio from inputs, using 16 bit data would lose some data, but it might be negligible as upper bits from the audio codec contain just noise. You’re still working with “CD quality” audio. If you still want to avoid losing some details that are below hearing threshold, you could try writing a custom 24 bit integer serialization class that would store more or less the same amount of data as 32 bit float for normalized audio.
Something as popular as MI Clouds supported different formats for its audio buffer, going as low-fi as 8-bit with companding at 16 KHz. Of course it was done out of necessity as it had no external SDRAM chip and had to fit everything in 192 Kbytes of on-chip SRAM
3 Likes
Also, @Os_Brennan, keep in mind that the Seed Data Sheet tells you about the Seed hardware primarily. You seem to be hitting some limitations of Arduino - you would probably not see those limitations with DaisySP-C++, or PureData-PD2DSY or MAX/MSP, etc, and you can find out about each package in its own documentation.
The stuff i read said “samplerate * time * number of channels * bit depth” so when you do the math and modify the sample rate of the looper function you can find you can get 10 minutes of audio at varying qualities up to a certain point depending on how it is set up. This didn’t add up to the same percentage the looper.cpp code generates in the SDRAM portion of displayed memory so I’m not certain why that is. If you set MAX_SIZE to 1 it results in 4 bytes being used iirc so 8 bits per byte means that’s 32 bits. At default the code uses something like 87% of the SDRAM.
I suggested that the seed have a larger size EEprom or flash IC instead of SDRAM for short term storage of non volatile loop recording but SDRAM forcing creativity seems an interesting idea as well.
The SD storage seems to be a more readily transferable system across many platforms so read/ write to/ from that might be why it is the way it is. You can record up to 1 terabyte at the highest sampling rate on those which would be a lot of audio and even more at lower sampling rates. If you created a voice filtering system to only store human voices it could store data from vocals over time for a long time and the limiting factor would be powering the device.
I find that audio quality input is probably more of the defining factor than the processing or storage abilities of the hardware so far but I’m still learning about it.