DSP Robotics Support

Hi,

I have 2 data streams going into my DLL and use an ASIO driver as the interface. I ASIO driver can be set to some sample range, but typically I have it set to 512 or 1024.

The two data streams are 2 different pairs of signals with different complexity and frequencies (my DLL finds when the data is similar between the then near zero crossings... more for data signal processing than for audio - but I use FlowStone for everything ...anyway)

Typically the frame size is gotten by this:

float* audio1 = GETFRAME(pIn[0]); //A frame is just a float array
float* audio2 = GETFRAME(pIn[1]); //A frame is just a float array
int frameSize = GETFRAMESIZE(pIn[0]);

I was wondering if this was valid as well:

float* audio1 = GETFRAME(pIn[0]); //A frame is just a float array
float* audio2 = GETFRAME(pIn[1]); //A frame is just a float array
float* audio3= GETFRAME(pIn[2]); //A frame is just a float array
float* audio4 = GETFRAME(pIn[3]); //A frame is just a float array
int frameSize12 = GETFRAMESIZE(pIn[0]);
int frameSize34 = GETFRAMESIZE(pIn[2]);

Or is the frame size ALWAYS equal for both (or each) data stream ?

Thanks,

Aron

if the two pairs come from the same ASIO driver, then they should match in framesize. In fact, I don't think it is possible to have two drivers running with the same app/plugin, so it should always be the same size for all buffers. I may be wrong though...

I can only think of one example when the buffersizes do not match - when you use ruby to generate a frame of different size.

KG_is_back wrote: In fact, I don't think it is possible to have two drivers running with the same app/plugin

for sure not as vst inside a DAW, and also not as executable becasue you need to set the audiodriver then!

Indeed, the framesize is consistent for all channels a driver can handle (which depends on the soundcard).

I'm not even sure if the named Ruby example would cause issues, since the (real) framesize is driver dependant. I might be wrong though.

You have to check the size because the user could change it in the driver settings on the fly, but you don't need to check it for each audio channel.

That is what I thought, so that is a good thing ! Well at least my thought process was correct on this...

I wanted to make sure because I was having a timing issue.
Maybe I need to delay by some number of samples...?

Back to coding.

Thanks for the comments / answers etc. !

Aron

Thanks for the help !

So a one frame delay was my solution for one of the two xy data channels... Seems to work well now, hope this is a valid thing to do (just converting it to a frame then back again...?) still using the DLL to process, and added a one frame delay.



I use FlowStone more for image processing than anything else, and so putting image processing in the audio domain allows me to do some cool things, but you have to think about data in a new an interesting way. Lucky my hobby is building analog electronics and synths !

Aron
FlowStone Rocks !

aronb wrote:Thanks for the help !

So a one frame delay was my solution for one of the two xy data channels... Seems to work well now, hope this is a valid thing to do (just converting it to a frame then back again...?) still using the DLL to process, and added a one frame delay.

One_Frame_Delay.JPG

I use FlowStone more for image processing than anything else, and so putting image processing in the audio domain allows me to do some cool things, but you have to think about data in a new an interesting way. Lucky my hobby is building analog electronics and synths !

Aron
FlowStone Rocks !

Hey Aron,

the one frame delay is normal and stated in the user guide. So you should be fine. Also interesting read about image processing in the audio domain. Hope you'll show us something when in good shape?