DSP Programming

C

Chris Brandt

Freshman
Mar 16, 2011
1
0
0
I am working on making a document to aid in properly programming an open architecture DSP. Things I am looking to explain are ideas like why limiters should go towards the end of the signal chain, should a delay or equalizer be first in line to minimize phase issues, why certain blocks go where they do.

I realize how many options there are when programming a DSP and it depends on the install, but some guidlines to follow would be helpful.

If anyone has thoughts or can point me to useful documents, that would be helpful.

Thanks,

Chris Brandt
Daktronics Audio
 
Re: DSP Programming

Chris Brandt said:
. Things I am looking to explain are ideas like why limiters should go towards the end of the signal chain,
Click to expand...

My understanding is that the limiter goes last in the chain so that you are limiting based on the final version of the signal. It would be a bit pointless to have a carefully set limiter, followed by an EQ with a +12dB boost in it.
 
Re: DSP Programming

Hi Chris-

How technical do you want to get? If you're distilling engineering-speak down to a "best practices" manual for installers of your employer's gear, I suggest you find local/regional audio folks to do this work. Video guys and riggers (most of them, anyway) don't understand audio at this level.

The gold-standards of reference are Sound Systems: Design & Optimization, 2nd by Bob McCarthy (Focal) and Sound System Engineering, 3rd by D. Davis and Patronis (Focal).

Have fun, good luck.

Tim Mc
 
Last edited:
Re: DSP Programming

I'm curious to know if there's a certain DSP that you want to model or are working with or we talking an open source code design that allows you move things? (Much like the inserts in a ProTools channel)

As Bennett stated it is what it is in the Phase department, even High Pass Filters cause phase shifts. I think that my preference would be somewhat in the order that I think for tuning a cabinet.

Source->In Compression -> In (global) EQ -> Master (global) Delay ->(Begin Outputs)-> HPF -> LPF -> EQ -> Output Delay-> Limiters

Funny thing is that it never appears in the order on a piece of hardware, suppose that it's set-up for all eq's to be at the end since the number of filters used is unknown and it could theoretically go on forever....

I'd be interested to read what you come up and compare notes.
 
Re: DSP Programming

Isn't the whole point of an open architecture DSP that it is open architecture and can be configured as one needs or desires for a specific application? There may be some general approaches and concepts that make more sense than others, for example limiters last if they are for system protection (not necessarily last if used for some other purpose), but "properly programming" an open architecture DSP unit seems to be more about knowing what the algorithms do, how they affect the signal and what you are trying to do for that specific application rather than following some preset guideline. If you had a particular application you could probably address that in specific, otherwise the point seems to be to not be locked into specific approaches but rather to have the underlying knowledge to implement the processing in a way that makes sense for any specific application.

What might be nice would be some guidelines for beginners on how to put some common algorithms together to create some typical 'blocks' such as a channel strip equivalent or a speech processor or a look-ahead limiter and some general information such as how a X band graphic EQ is often equivalent in terms of processing to X bands of parametric EQ and the practical differences between FIR and IIR filter implementation.

Added: In a very simplified perspective, most open architecture DSP devices provide algorithms that emulate analog device functions, so how you configure those devices is genrally no different than it would be in the analog world. There are some specifics issues such as processing latency, delay compensation, FIR versus IIR, etc. that are not relevant to the analog analogs, so maybe that creates some division for adddressing the different aspects involved.
 
Last edited:
Re: DSP Programming

Pet peeve of mine, but it would be nice to have a few text blocks in the design describing what is being done, along with communication settings, so that when the design is re-visited a couple years down the road, you don't waste time trying to figure out what was done or how certain presets work, and how to hook up to the processor! Even text identifying inputs and outputs goes a long way to keeping things in order! Unfortunately when I come in to figure out what's wrong with a DSP, typically I see a rat's nest of connectors and blocks, and absolutely no documentation within the DSP! Ah well, more billable hours!

With regards to layout, a healthy dose of common sense is in order. I troubleshoot a lot of designs over the course of a year, you can tell the difference between a design by a video or Crestron programmer and a design made by an audio pro, the former will have graphic eq blocks scattered everywhere! Parametric eq? What's that? :)
 
Chris Brandt said:
I am working on making a document to aid in properly programming an open architecture DSP. Things I am looking to explain are ideas like why limiters should go towards the end of the signal chain, should a delay or equalizer be first in line to minimize phase issues, why certain blocks go where they do.

I realize how many options there are when programming a DSP and it depends on the install, but some guidlines to follow would be helpful.

If anyone has thoughts or can point me to useful documents, that would be helpful.

Thanks,

Chris Brandt
Daktronics Audio
Click to expand...

This would be a great article for the wiki!
 
Re: DSP Programming

Arthur Skudra said:
Pet peeve of mine, but it would be nice to have a few text blocks in the design describing what is being done, along with communication settings, so that when the design is re-visited a couple years down the road, you don't waste time trying to figure out what was done or how certain presets work, and how to hook up to the processor! Even text identifying inputs and outputs goes a long way to keeping things in order! Unfortunately when I come in to figure out what's wrong with a DSP, typically I see a rat's nest of connectors and blocks, and absolutely no documentation within the DSP! Ah well, more billable hours!
Click to expand...
Not just in the troubleshooting later but if you are designing a system that someone else may program or programming a system that someone else designed then also in defining what is initially intended. Even simply identifying inputs, outputs and blocks by relevant names can be a great help.
 
Top Bottom