Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 7 of 7

Thread: IRQ/ISR issues with my float version of AudioStream

Hybrid View

  1. #1
    Member
    Join Date
    May 2021
    Location
    Sweden
    Posts
    26

    IRQ/ISR issues with my float version of AudioStream

    I decided to make a version of AudioStream that works with float32_t instead of int16_t for use in an SDR project based on a Teensy 4.

    I just got it to work, but not in a very elegant way. I need it to work alongside the normal AudioStream system, which required a bit of ugly hacking. I hope there is a more elegant way to get the two to work together.

    I think the issue I have is that there is a software interrupt that drives a large part of the AudioStream action and now I need the interrupt to call both the original software_isr() routine in AudioStream.cpp as well as my new software_isr_float() routine in my new file AudioStreamFloat.cpp. The interrupt is set up in AudioStream.cpp like this:

    Code:
    bool AudioStream::update_setup(void)
    {
    	if (update_scheduled) return false;
    	attachInterruptVector(IRQ_SOFTWARE, software_isr);
    	NVIC_SET_PRIORITY(IRQ_SOFTWARE, 208); // 255 = lowest priority
    	NVIC_ENABLE_IRQ(IRQ_SOFTWARE);
    	update_scheduled = true;
    	return true;
    }
    (Strangely enough IRQ_SOFTWARE is 70, which is "Reserved" in table 4-2 in the i.MXRT1060 datasheet. But this is probably irrelevant to this discussion.)

    Here is the corresponding code in AudioStreamFloat.cpp:

    Code:
    bool AudioStreamFloat::update_setup(void)
    {
    	if (update_scheduled) return false;
    	attachInterruptVector(IRQ_SOFTWARE, software_isr_float);
    	NVIC_SET_PRIORITY(IRQ_SOFTWARE, 208); // 255 = lowest priority
    	NVIC_ENABLE_IRQ(IRQ_SOFTWARE);
    	update_scheduled = true;
    	return true;
    }
    Depending on the order in which objects are allocated, either one of these routines may run last and that takes over the interrupt so that the other kind of AudioStream does not get any calls to its software_isr routine.

    Right now my solution is to add a call to software_isr() at the end of software_isr_float() and make sure I allocate all my objects using the original AudioStream system before I allocate the objects using AudioStreamFloat.

    I guess this could be solved either if there is a way to set up a separate interrupt to call software_isr_float() without interfering with the interrupt calling software_isr(), or if there is a way to make it so that both routines are called by the same interrupt. I am also open to other suggestions on how to solve this issue in a more elegant way than what I have today. I would prefer not to modify the original AudioStream.cpp/AudioStream.h files.

    Per

  2. #2
    Senior Member
    Join Date
    Jul 2020
    Posts
    1,345
    You could use the same system, but have some objects that treat the audio blocks as arrays of float
    rather than int16_t. You'd need two blocks per stream as sizeof(float) = 4 and sizeof(int16_t) = 2.

    Clunky in a different way...

  3. #3
    Member
    Join Date
    May 2021
    Location
    Sweden
    Posts
    26
    Hi MarkT,

    Thanks for the suggestion. That might have been simpler to implement, but now that I have a working (but clunky) solution, I am reluctant to change to another clunky solution. I would prefer to polish this solution I have. If possible.

    Per

  4. #4
    Senior Member
    Join Date
    Oct 2015
    Location
    Vermont, USA
    Posts
    314
    There are several other folks who have done this, so you could look at their solutions.

    The OpenAudio library and Tympan_Library both derive from my way of extending the teensy audio system to floating point.

    Here is the OpenAudio version that shows my definition for the audio block, the audio connection, and the audio stream. https://github.com/chipaudette/OpenA...ioStream_F32.h

    It's the AudioStream_F32 that is most important. Note that I inherited from the regular AudioStream. This way, both the base Teensy library and the extended f32 library can play together.

    Chip

  5. #5
    Member
    Join Date
    May 2021
    Location
    Sweden
    Posts
    26
    Thanks Chip. I clearly did not google enough before starting to write code. I will look into the solutions you point to.

    Per

  6. #6
    Senior Member Blackaddr's Avatar
    Join Date
    Mar 2017
    Location
    Canada
    Posts
    328
    I can also vouche to take a look at Chip's OpenAudio extentions rather than start from scratch.

    However, many effect developers also find it easier to simply convert to/from float in side their update() function and retain the 16-bit audio stream transport so consider that option as well. There are CMSIS DSP functions to accelerate the conversion on the Teensy.

  7. #7
    Senior Member
    Join Date
    Oct 2015
    Location
    Vermont, USA
    Posts
    314
    And I can vouch for Blackaddr's Teensy-based Guitar Audio Shield. It's fun!

Posting Permissions

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