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

Thread: Dynamic allocation of audio objects

  1. #1
    Junior Member idek's Avatar
    Join Date
    Oct 2020
    Location
    Hungary
    Posts
    4

    Dynamic allocation of audio objects

    (I'm not sure if this forum is the best place to post this, sorry.)

    On the Audio Roadmap page, there's this bit of text under "Dynamic Updates & Web Designer Control":
    "the audio objects really need to be statically allocated"

    Why is this the case? I'd like to allocate them dynamically. Can I do anything to help?

    Thanks,
    idek

  2. #2
    Senior Member
    Join Date
    Jul 2020
    Posts
    469
    From what I've seen of the codebase (T4 only) it might work to use new and delete, I've not tried myself. I suspect
    there's been little testing so some things may work, others not... On the T4 the performance of dynamic memory is
    less and I'm not sure what the implications are for DMA, so I'd statically allocate input and output objects anyway.

    Others may have some actual experience trying this?!

  3. #3
    Junior Member idek's Avatar
    Join Date
    Oct 2020
    Location
    Hungary
    Posts
    4
    Quote Originally Posted by MarkT View Post
    From what I've seen of the codebase (T4 only) it might work to use new and delete, I've not tried myself.
    It also mentions that the constructor is unable to add objects and connections to a live system right now, so it may require extensive code modification.

    My current roadblock right now is being unable to find the AudioConnection class in the codebase :$

    EDIT: Found it (avr/cores/teensy3/AudioStream.h, avr/cores/teensy4/AudioStream.h)
    Last edited by idek; 10-23-2020 at 03:21 PM.

  4. #4
    Senior Member
    Join Date
    Jul 2020
    Posts
    469
    It's in AudioStream.h, in cores/teensyX:

    For instance: https://github.com/PaulStoffregen/co...master/teensy4

  5. #5
    Junior Member idek's Avatar
    Join Date
    Oct 2020
    Location
    Hungary
    Posts
    4
    I've dug around with AudioConnections, and I can see 2 things that could cause issues:
    * The connection might not work immediately, only when a new audio block is transmitted by the source. (see: https://github.com/PaulStoffregen/co...tream.cpp#L150)
    * When the AudioConnection is connected (initialized), it disables IRQ while it adds the connection to the source and destination streams, which might cause brief audio glitches/dropouts? (see: https://github.com/PaulStoffregen/co...tream.cpp#L194)

    I haven't looked at adding other new Audio objects in detail, but AudioStream also disables IRQ while doing memory stuff when initializing, so that might also be an issue.

    Note that I am not very familiar with the codebase, so I might just be blatantly wrong

  6. #6
    Junior Member idek's Avatar
    Join Date
    Oct 2020
    Location
    Hungary
    Posts
    4
    Actually, IRQ disables happen all the time when AudioStreams are updating (see https://github.com/PaulStoffregen/Au...delay.cpp#L100 for example), so messing with IRQ might not cause an issue if new objects are created at the right time (somewhere over here maybe).

  7. #7
    Senior Member
    Join Date
    Jul 2020
    Posts
    469
    Quote Originally Posted by idek View Post
    I've dug around with AudioConnections, and I can see 2 things that could cause issues:
    * The connection might not work immediately, only when a new audio block is transmitted by the source. (see: https://github.com/PaulStoffregen/co...tream.cpp#L150)
    * When the AudioConnection is connected (initialized), it disables IRQ while it adds the connection to the source and destination streams, which might cause brief audio glitches/dropouts? (see: https://github.com/PaulStoffregen/co...tream.cpp#L194)
    Both these things happen already as the static initialization proceeds AFAICT. Disabling interrupts is absolutely essential to prevent
    the datastructures being corrupted during the connection changes, and remember this might last a few 100's of nanoseconds,
    whereas the audio related interrupts are every 2.9ms, and audio ISRs are updating buffers for the next 128 samples so
    can afford to be delayed for quite a while.

    One thing that I could see causing issues dynamically is deleting the AudioStream that's currently got update responsibility - I don't
    think this will work (you'd need to iterate over the other active streams and assign a new one if possible, else switch off
    the audio system). Pretty sure I didn't see anything like this in the sources.

Posting Permissions

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