Using AudioStream::allocate() from AudioControl objects

Status
Not open for further replies.

palmerr

Well-known member
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:
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.
 
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.
 
Status
Not open for further replies.
Back
Top