question to devs about DSP coding

dendy

started a digging a bit into iOS DSP coding (for curious people, no plans for app yet, just spending some free time learning stuff

my questions to devs here - are you using vDSP in your apps ? There is stated that some provided math operations can run multithreaded - so there is way to build multithreaded audio apps... is there any constrain which prevents of using vDSP ?

Thanks for tip or advice

McD

NOT A DEVELOPER but I like to look things up.

Apple states:

The majority of vDSP operations are single-threaded and run on a single core. However, the following functions may be multithreaded depending on the size of the data they are operating on:

vDSP_mmul(::::::::_:)

vDSP_mmulD(::::::::_:)

vDSP_zmma(::::::::::_:)

vDSP_zmmaD(::::::::::_:)

vDSP_zmms(::::::::::_:)

vDSP_zmmsD(::::::::::_:)

vDSP_zmmul(::::::::_:)

vDSP_zmmulD(::::::::_:)

vDSP_zmsm(::::::::::_:)

vDSP_zmsmD(::::::::::_:)

So, basically a collection of Matrix manipulations may be multithreaded depending on the amount of data. I'll bet it's a bitch to debug if it comes to that and makes the application work well on some iPads and not so well on others.

I do hope a real developer slips you a clue or 2.

dendy

yes you may be true.. it's just subset ... ím interested about some practical experience, you know stuff what you don't find sp eqsily in manuals... as i said, i'm just curious, for now just trying to understand it...

i have 25 years of experience with coding, althougjt not DSP related, i'm more in client-server apps, processing big data, webservices, databases, speed optimalisation and stuff like that...

but decided to learn new stuff and i understand basics of DSP (till yet mostly experimenting in Max8), there is lot of docu on web, but you know - searching also for practical experiences, it can often save lot of time studyinh manuals just to realise you're going in wrong direction :-)

brambos

Yes, I use it sometimes. However, I encourage you to leave the optimisation stuff until the very last step. First get it working and sounding exactly like you want it to using regular maths stuff. It's much easier to conceptualise and debug.

Then slowly work your way through the code and replace bits with this stuff one by one. You will break things, and this method will tell you immediately where you messed up.

Also, keep the original code somewhere. Don't delete it because you may need it in the future when porting to another platform/architecture or system.

rs2000

As with multi-threading in general but especially with audio processing, it's certainly worth to think about what benefit processing in multiple threads will actually bring.
Which of the processed results do you need at what time?
Which input depends on which output at what time?
How much data is there to move between threads?
Do you need semaphores blocking data as long as it's not processed by another thread?
It may sound counter-intuitive but I would say that optimizing the DSP code itself is so much more important than multi-threading support.
Remember the first iPad appearing in 2010?
It was already able to run Propellerhead thor, Arturia iMini and many other cool synths although its CPU performance was a joke compared to current models.
But hell, that code must have been really good! 😎

rs2000

There's a really nice, high-quality open source project that came loooong before AudioKit Synth One:
http://rrr00bb.blogspot.com/2010/08/mugician-heiroglyphics.html

Links to video demos and github source repo are included 😎

polaron_de

@dendy said:

my questions to devs here - are you using vDSP in your apps ?

Yes.

% grep -s vDSP Thafknar/*/*/* | wc -l
40

% grep -s vDSP Napo/*/*/* | wc -l
61

dendy

@brambos said:
Yes, I use it sometimes. However, I encourage you to leave the optimisation stuff until the very last step. First get it working and sounding exactly like you want it to using regular maths stuff. It's much easier to conceptualise and debug.

Then slowly work your way through the code and replace bits with this stuff one by one. You will break things, and this method will tell you immediately where you messed up.

Also, keep the original code somewhere. Don't delete it because you may need it in the future when porting to another platform/architecture or system.

Yeah you pretty much exactly described my way of coding I always wrote in first round something what just works, and then i go through series of "reducing" rounds where i basically try to delete and simplify as much code as possible with preserving initial functionality Sometimes it's good just to know about some possibilities, even through you don't use them - but it helps you write code ready for later improvement. You probably know that ))

As i said, currently i'm in stage of trying to get basic overview about what is possible, to connect things together. Just to know about it, to understand basics. You need to know what you don't know to be able to learn it . I'm far away wrom starting to write some real code (i didn't count stuff i build for myself in Max just to get familiar with elementary DSP principles), i'm just gathering knowlege and building mental map of this area It's something which interests me for years but i finally decided to dive deeper into it.