DSP Robotics Support

Hi all

For purposes related to R&D of high-end audio systems, I am currently developing an equalizer tool with both FIR and IIR integrated. It is largely based on contributions from others in this forum, like Martin Vicaneks FIR algorithms. I have taken the liberty to adjust the GUI and gear it towards the typical stereo-audio developer, with a "proper" BODE graph etc.



The non-surprising mandatory and general requirements I have defined for this work:
1. No audio quality corruption. (For example, artifacts close to the Nyquist, proper IIR modules, etc)
2. Scrupulously, no modules that triggers the CPU usage problem of Flowstone. The current version is not CPU intensive. It is a 0.0% here

Would anyone be interested in taking a look at it?

For example, I just made my first ever Ruby code and it could need a ruby expert to review it.
And, are there other things I have done that is less than optimal, generally "Flowstone" speaking?
Are there any modules available in this community that you would suggest to be integrated?
In particular, has anyone made a systematic multi IIR module of proven audio quality?

Regarding FIR: I do not comment now, but there are several very interesting features that could be included, some of which have already been presented in this forum. One thing is the number of Taps, which needs to be generalized. A slider is included to indicate that.

This version: Contains 2 IIR modules just to show features. One can imagine e.g. 8 instances. Number of IIR instances can be adjusted with sliders. There is this and that clickable button (toggles). Try! Only PEQ and 1pole shelf is included, so the IIR module has some TODOs.

There are more TODOs inside. Would anyone be interested in partaking in finishing up this Equalizer as a general purpose tool? If so, we could create a "token" so that one participator at the time made his/her adjustments, then the next, etc. But some modules, like FFT dynamic graph, could be developed in autonomic mode, then inserted back.

For me, this would be 1+ week of work. For more competent personel, much less. So it is not a large project.

The first milestone is to complete this module with e.g. all iir types, one graph (two now, overlayed), proper preset mng, etc. Then some added features, like a smoothed curve dynamic FFT display (rocko's version is inside but not connected). It is not really that much work, but I will strive with Ruby and hope someone more competent could take a look at some of the TODOs indicated, like integrating the curve graphs into one module.

AFTER THAT, I will develop this further into a live loudspeaker prototyping tool. To my knowledge, a "live" tool with which one can develop e.g. a 3 way system, is not in existence. It would attract attention among speaker builders because it would be a huge timesaver to be able to do all development in this tool, then export results to either a passive or a active crossover. Such a tool would also need import and export features, e.g. speaker driver measurement, a house curve, and more.

But first I hereby investigate if anyone would be interested in collaboration.

Thanks!

I'm not sure to which other Ruby code you refer to, but I had a look at "Log-Lin Resample".

There are only two aspects to be considered. Currently, no event management takes place in the RubyEdit. That means the whole code is run for every (external and internal) trigger. Basically you give control out of hand, and the code is run even on triggers, where it isn't necessary (for example internal back triggers). To prevent this, place your complete code into a



The for loop is inefficient and slow. It is just a wrapper to the enumerable anyway, so better use that.


In general, I can see that you are not used to OOP. That's ok, the code will work, but you make your life much harder. The object oriented approach here would be to think "ok, it is all about the array b, this is what gets outputted, so lets wrap my code around this array". Therefore, make yourself comfortable with the many methods, an array provides. You will see, that you don't need any of your "non-oop" constructs.

For example, any array can be iterated through, using


As I undersand you fill an array b with values calculated inwards, so that the end point is the middle of the array. I would do it by creating two arrays of same length, ary_a and ary_b, and fill both non-reversed with .map!, then when done, use ary_b.reverse!, which is a method of an array that reverses the order, and finally add them together at the output stage, like output(0, ary_a + ary_b)

That is not necessarily faster (although I'm confident), but it is much better maintainable - and readable for others.

Excellent. That module is not my code, and I am yet to look into it, but your comment will be taken into consideration (and probably changed). If you would like to change it, be my guest! I am used to OOP from Java, but at the moment I am not yet able to spot these mechanism in Ruby.

I am away for accounting work a couple of days, and will let this thread mature meanwhile in case of - and hope for - other suggestions.

"my" ruby code is in the two graphs modules only, originally from Vicanek, where I added minor changes, like margins, and where I splitted an original graph module into two new ones, one taking care of the basic graph, the other taking care of the FIR curve. The latter should also take care of the IIR curve per my suggestion. I did that mostly for my own, to not have too large ruby modules that I would probably mess up sooner or later. Mostly a lack of ruby self confidence, IOW, but I found it tidy also. Agree?

If 'T' is posting .... I'm watching this thread.

Thanks

Hej chjan,
I can help with the DSP side of the project. Some immediate comments on your schematic:

1. You make frequent use of selectors (and multiplexers). Bear in mind that upon switching, these interrupt the audio and recompile the schematic. As an alternative, consider multiplying by 1 or 0 (or even a ramp for soft switching).

2. Inside the schematic you mention Linkwitz Riley crossover. IIRC I posted a schem some time ago, it might even be linear phase.

3. Today I would not use direct form biquads for high quality audio, not even in static filters. I can offer better implementations.

4. I also have better matched magnitude responses for peaking EQ, shelving filters etc. today than I had back then.

5. Today I would definitely use a longer FFT than 1024, preferrably make it user selectable as you suggest.

6. One could use partitioned convolution to reduce latency in FIR filtering.

7. This project is >> 1 week.

8. Please advise if you post schematics made with FS alpha.

Great!

Unfortunately, I MUST do accounting for a few days, but immediately after that, I will return. Thanks for response which is very good looking. I had a quesiton on tongue regarding multiplexer and whether the underlying code does a pointer shift or arraycopy or.. but I must know more about that. Indeed.

Much more that one week. Well, one must cope with that. I have a rough overview of what you have done on FIR techniques, and I have some interesting suggestions that could create a little revolt in the speaker developing business and so get attention.

If you want to fix my mistakes, grab the token.

So, a few days...

Sorry to butt in, but Martin's comment about selectors/multiplexers, and using multiplying by 1 or 0 (or using a ramp for soft switching) instead is most likely relevant to me as well, since I tend to add options as I go, and always want to make sure whatever it is (usually a modulator of some type) has at least an on/off switch... might there be already a good example schematic demonstrating these "better replacement" methods, and, if not, might it not be helpful to the more thick-headed like me (or those newbies who have yet even to understand why people keep going on about why doing this or that "in green" isn't ideal, etc.) to post one? I honestly would be happy to throw a few clams at somebody willing to create a "Do THIS, not THAT" series of schematics

I now return you to your regularly scheduled topic

I am another thick-head, sort of, and support your question! But I reckon Martin will show us shortly.

BACK FROM ACCOUNTING. I RESPOND; THUS:

Some immediate comments on your schematic:

1. You make frequent use of selectors (and multiplexers). Bear in mind that upon switching, these interrupt the audio and recompile the schematic. As an alternative, consider multiplying by 1 or 0 (or even a ramp for soft switching).

Would it be possible for your to show an example schematic (module) that could be used to replace selector and multiplexer? Is the recompile affecting the schematic ONLY when the switch is done, or could there be audible consequences when the switchs have been set?

2. Inside the schematic you mention Linkwitz Riley crossover. IIRC I posted a schem some time ago, it might even be linear phase.

LR crossover is one thing. For a speaker prototyping tool, all the major filter types should be selectable, like LR, Cheby., Butterworth, etc. There are even special filters like Duelund variants and others.

Phaselinear vs Minimum phase: Per definition LR and others are minimum phase, but it would be VERY interesting to present a linear phase variant of e.g. 1st, 2nd, 3rd etc order filters, as well as a brick wall variant.

What I meant here, not precisely descriped, is the LinkwitzR bass compensation circuit that is VERY common for active subwoofers and speakers. Because the speaker itself is normally minimum phase, the LR circuit will flatten the response (in principle) and therefore also the phase response, thus creating a linear phase end results. It is this LR EQ circuit that needs to be available as a feature. It has 2 poles and is not unlike shelf filters.

3. Today I would not use direct form biquads for high quality audio, not even in static filters. I can offer better implementations.

As time allows, please present them! I have read your White paper on some of this, but it would be very good if you have reasons (mathematical or otherwise) to illustrate the weakness in direct form bquads, vs strength in your own implementation.

4. I also have better matched magnitude responses for peaking EQ, shelving filters etc. today than I had back then.

Same response, please present.

5. Today I would definitely use a longer FFT than 1024, preferrably make it user selectable as you suggest.

That's why I made the tap-slider and ms delay indicator. Brick walling at lower frequencies requires larger nof taps. I have java code for producing FIR filters in whatever tap dimension, but nothing for Flowstone. There are a few other things you have that is also very interesting. One is the ability to automatically reproduce/mimic an arbitrary SPL response, only, it could be used the other way around; to create the reciprocal (inverse curve) of such a response. That would be a great tool to check how your speakers are sounding when flattened in its response. One could then add a simple "house curve" as it is called, e.g. the Harman Kardon "default", and incorporate that response to the SPL response and therefore create a "flat" and(or hourse curve response for a speaker system.

Another interesting feature would be to use the same principle to rectify a systems measured phase response. The reading in of SPL and Phase response should be easy peasy, for example as produced as results from the use of REW, a free tool used by the whole world. REW can export as txt, convolution or other formats. Same with impulse response, it can also easily be retrieved from REW.

6. One could use partitioned convolution to reduce latency in FIR filtering.

Please explain in more detail.

7. This project is >> 1 week.

Yes, but the basic equlizer tool should be first milestone, and when that is available it is available for this and that new project. That should not be more than a week, with the exception for replacing Flowstone Biquad with enhanced versions etc.

8. Please advise if you post schematics made with FS alpha.

I use 3.09 B2. Unaware of alpha versions. Should I swap to a newer version (or older)? Please advice

Here is a set of matched (static, i.e. not modulateable) standard filter types.

I'll also respond to the other points, bear with me.