Change Audio Block Size

Status
Not open for further replies.
Maybe yes, your're right. Do you have time to repair the fft ? :)
There might be other minor problems, too.
Audio-Output works well.
I'm looking through the Audio Objects to see where array overruns and such would occur and have not found any except for FFT1024. I haven't tested anything though. One thing with lowering the block size would be to increase the number of interrupts per sample rate if that matters?
 
Here is a pullrequest:
https://github.com/PaulStoffregen/c...7e15715747b02d8266b7d0bd4287351bf1?diff=split

With this little upate, it is possible to use the commandline to set the blocksize.
Ok, Arduino does not support this, at the moment (but you can edit boards.txt, use an other ide, or, simplest, my "defs.h"-"hack") This way, it is not needed anymore to edit the core-sourcecode.


One thing with lowering the block size would be to increase the number of interrupts per sample rate if that matters?
No sure if I understand :) It increases automatically when changing the blocksize or samplerate. Have i misunderstood you ?
Anyway, If someone changes these parameters, it is a logical consequence that the interrupts per second change. Sometimes this is wanted, for example to decrease the lag.

Edit:
I guess, wer'e getting closer to enable the Teensy-LC for the audio-lib :) The only thing missing is to make the in- and outputs working !
Edit:
(ok, and perhaps to add some code that does not need the DSP-Extensions.. should be easy.)
 
Last edited:
Why is AudioStream.h in cores instead of in the Audio Library? It's easier for users to modify things in libraries than in cores, especially if a person forks the Audio repo and clones it into Documents\Arduino\libraries. Forking cores is a lot more annoying since one still has to install Teensyduino (to get the mods to the IDE), delete cores, and clone cores. Much more annoying to communicate to people who are less plugged in.

Is it possible to move AudioStream over to the Audio library?

Chip
 
Why is AudioStream.h in cores instead of in the Audio Library?

Mostly for the USB Audio feature.

Implementing the basic connectivity it the core library also allows features to be developed as separate libraries, like Frank's work with the Helix MP3 library.
 
No sure if I understand :) It increases automatically when changing the blocksize or samplerate. Have i misunderstood you ?
Anyway, If someone changes these parameters, it is a logical consequence that the interrupts per second change. Sometimes this is wanted, for example to decrease the lag.
From what I see changing the block size to lower value (power of 2) would increase the amount of audio library update interrupts because the sample rate would not change just less samples are collected before update_all() is called. I could be wrong though?
 
Yep; agree. Thats the way it works. The samplerate stays the same, so the number of samples stays the same. Half blocksize means double interrupts. Unless the samplerate is decreased, too.
 
Last edited:
Yes, the interrupt rate increases with smaller block size. There's also overhead in many of the audio algorithms, and the simple matter of allocating and sharing blocks of data as audio streams are communicated between the objects. As the block size shrinks, that fixed overhead becomes a larger percentage of the total CPU time used. This overhead was the main reason why I chose 128 samples as the default block size.
 
So there is a way for minimize the latency?
I am trying to stream to the USB and I got big latency
my code is very simple, how can i decrease the latency? maybe some changes in the pc buffer?
 
Latency on the Teensy side should be under 10 ms, unless of course you've intentionally added the delay effect or other delay-based processing (like reverb).
 
Latency on the Teensy side should be under 10 ms, unless of course you've intentionally added the delay effect or other delay-based processing (like reverb).

Hi Paul,
while streaming the signal from the LINEIN to the LINTOUT on the audio board I hear no latency, probably that's under the 10ms you told,
While trying to stream the signal to the USB output, I got much more latency,
AudioInputI2S i2s1; //xy=286,151
AudioOutputUSB usb1; //xy=623,232
AudioConnection patchCord1(i2s1, 0, usb1, 0);
AudioConnection patchCord2(i2s1, 1, usb1, 1);
AudioControlSGTL5000 sgtl5000_1; //xy=261,231
// GUItool: end automatically generated code



void setup() {
AudioMemory(12);
sgtl5000_1.enable();
sgtl5000_1.volume(0.6);
sgtl5000_1.lineInLevel(16);
}
I Just chose the "listen to this device" on the Sound control in my Win10,
Do you have any idea how can i decrease this latency?
Thanks!
 
I Just chose the "listen to this device" on the Sound control in my Win10,
Do you have any idea how can i decrease this latency?

No, I'm sorry, I do not use Windows much (I mostly use Linux), so I'm just not familiar with the finer points of configuring Windows.

It's also quite possible the latency could be a result of buffering in whatever software you are using on Windows. Can you read your question and try to understand how even a Windows expert could not possibly know what you're really doing, even which program you're using, from so little info in your question?
 
I realized that I never closed out the question in my original post. I was successful in making my floating-point audio library have user-configurable sample rate and block size. Because of how deeply the #define statements in AudioStream.h pervade the whole library, and because there's no way to overwrite those without having a user have a forked version of the Teensy Audio library, I decided just to encapsulate the functionality within my floating-point audio library.

A key requirement for me was to enable the user to change the block size and sample rate without changing a #define in any library files. Libraries are supposed to be pretty stable, so anything intended to be user controllable should be exposed via some sort of API. So, I created a new settings class: AudioSettings_F32, which you can instantiate via a call like:

Code:
const float sample_rate_Hz = 24000.0f ; //24000 or 44117.64706f (or other frequencies in the table in AudioOutputI2S_F32
const int audio_block_samples = 32;  //do not make bigger than AUDIO_BLOCK_SAMPLES from AudioStream.h (which is 128)
AudioSettings_F32 audio_settings(sample_rate_Hz, audio_block_samples);

Then, you go and create your audio-related objects by handing them (or, if you prefer, later passing them) the audio settings object:

Code:
AudioSynthWaveformSine_F32  testSignal(audio_settings);          //use to generate test tone as input
AudioInputI2S_F32           i2s_in(audio_settings);          //Digital audio *from* the Teensy Audio Board ADC.
AudioOutputI2S_F32          i2s_out(audio_settings);        //Digital audio *to* the Teensy Audio Board DAC.

If you're interested, you can check it out in my GitHub...

Example sketch is here: https://github.com/Tympan/Tympan_Li...WDRC_8BandCompressor/WDRC_8BandCompressor.ino

Full Library is here: https://github.com/Tympan/Tympan_Library

So, to my eyes, I was unable to find a simple, lightweight way to change the blocksize and samplerate throughout the standard Teensy Library without forking it and changing the #define statements. To get the functionality that I wanted, in the way that I wanted it, I had to do this replumbing, which basically moves me off from being dependent upon the Audio library at all. Is that really what I wanted to do either? No. But you know how personal software projects get...they often don't stay within their originally-planned box. :)

Chip
 
I was successful in making my floating-point audio library have user-configurable sample rate and block size. Because of how deeply the #define statements in AudioStream.h pervade the whole library, and because there's no way to overwrite those without having a user have a forked version of the Teensy Audio library

It's just a #define - in the last versions you can set via GCC-Commandline. There are several ways to do this, no need to fork the lib.
For example, -DAUDIO_BLOCK_SAMPLES=128

The one I use (because it is settable in the so-called "IDE" on a per-project basis) is with the "defs.h"


 
Status
Not open for further replies.
Back
Top