Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 41 of 41

Thread: Change Audio Block Size

  1. #26
    Senior Member duff's Avatar
    Join Date
    Jan 2013
    Location
    Las Vegas
    Posts
    969
    Quote Originally Posted by Frank B View Post
    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?

  2. #27
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Here is a pullrequest:
    https://github.com/PaulStoffregen/co...bf1?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.


    Quote Originally Posted by duff View Post
    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 by Frank B; 02-12-2017 at 09:09 AM.

  3. #28
    Senior Member
    Join Date
    Oct 2015
    Location
    Vermont, USA
    Posts
    187
    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

  4. #29
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,551
    Quote Originally Posted by chipaudette View Post
    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.

  5. #30
    Senior Member duff's Avatar
    Join Date
    Jan 2013
    Location
    Las Vegas
    Posts
    969
    Quote Originally Posted by Frank B View Post
    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?

  6. #31
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    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 by Frank B; 02-13-2017 at 05:29 AM.

  7. #32
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,551
    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.

  8. #33
    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?

  9. #34
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by alonper View Post
    I am trying to stream to the USB and I got big latency
    How big is it ?

    Quote Originally Posted by alonper View Post
    how can i decrease the latency?
    for the Teensy part, read this thread ;-)

    Quote Originally Posted by alonper View Post
    maybe some changes in the pc buffer?
    don't know.

  10. #35
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,551
    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).

  11. #36
    Quote Originally Posted by PaulStoffregen View Post
    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!

  12. #37
    Junior Member
    Join Date
    May 2016
    Posts
    6
    hi alonper,
    i think lineInLevel is (15) max, I do not know what 16 does?
    Last edited by djimip; 03-16-2017 at 12:34 PM.

  13. #38
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,551
    Quote Originally Posted by alonper View Post
    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?

  14. #39
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Yes, and how do you measure the latency ? How much is it ?

  15. #40
    Senior Member
    Join Date
    Oct 2015
    Location
    Vermont, USA
    Posts
    187
    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_Lib...Compressor.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

  16. #41
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,679
    Quote Originally Posted by chipaudette View 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
    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"



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •