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

Thread: Using AudioStream::allocate() from AudioControl objects

  1. #1
    Member
    Join Date
    Aug 2016
    Location
    Australia
    Posts
    26

    Using AudioStream::allocate() from AudioControl objects

    Hi,

    I'm working on an ethernet transport layer for the audio library - I have the basics working: input, output and control objects on T3.6 and T4.0 using Wiznet5500 modules. So far, I have tested transmitting synth'd sine waves over ethernet and playing them at the other end.

    Because of the shared nature of the ethernet (control) layer, it makes more sense to queue incoming and outgoing audio blocks at that (AudioControl) layer rather than in the input and output (AudioStream) objects.

    I'd love to use the audio buffer pool, i.e. allocate(), but it's only available to AudioStream objects. Is there a way around the limitation? I've been scratching my C++ head and haven't come up with a solution.

    I'm considering creating a "dummy" AudioStream object alongside the ethernet AudioControl object and leveraging that for buffers.

    If not, I'll just use static local buffers - but that's not quite as elegant.

    Richard
    Last edited by palmerr; 11-03-2019 at 05:48 AM.

  2. #2
    Senior Member Blackaddr's Avatar
    Join Date
    Mar 2017
    Location
    Canada
    Posts
    242
    Quote Originally Posted by palmerr View Post
    Hi,
    I'm working on an ethernet transport layer for the audio library - I have the basics working: input, output and control objects on T3.6 and T4.0 using Wiznet5500 modules. So far, I have tested transmitting synth'd sine waves over ethernet and playing them at the other end.
    Cool! In order to use the built-in allocate() and release() functions (which would let you avoid implementing a pool manager) you must inherit the AudioStream class, otherwise you'll need to hack the code out in a copy-and-paste and miss out on any fixes/updates in the main codeline. You don't have to create a separate dummy object per-say, just have whatever class you wrote that wants access to these functions to inherit AudioStream and initialize it's constructor. Maybe that compromise won't be too bad.

  3. #3
    Member
    Join Date
    Aug 2016
    Location
    Australia
    Posts
    26
    Thanks.

    I hadn't thought of that approach - I learnt my C in the late 70's (porting Unix kernels) and have had to add the ++ later in life, so I sometimes I miss something basic in OO.

Posting Permissions

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