Spectrum analyzer possible in DSP?

TheKezReturns · Jan 17, 2009, 09:01 PM

I was in a guys studio the other week and he had the realtime spectrum analyzer from his RME interface running permananetly on a second monitor.
It's part of the driver and runs independantly of asio hosts ect. This is great for cross refernecing against mp3s ect and having to insert a vst plugin on the master and every time and work a way to get it visible permanently just isn't the same. Also, this one could almost fill the whoile screen.
I've even heard of people running a whole spare PC just for this..... A KX Dsp plugins would be much neater.

I'm not sure how they work. I'd make a guess and say some sort of FFT and I know this has been said to be inpractical to do in DSP in most cases, but considering it just has to break the frequency bands up and display them, could it be done?

Obvisuly, sound quality isn't an issue and there's no processing or recombining of the bands to deal with. As far as resources, I'd be happy if the DSP was devoted to one really useful thing, considering everything else is better in vst plugin form these days anyway.

TheKezReturns · Jan 18, 2009, 07:04 PM

This was brought up once before but nailed quickly with a 'just use this expensive software' kinda answer. But a dedicated, non cpu intensive, permanently running analyzer thats monotoring everythig that comes out the main outputs is really what I'm hoping for.

Someone just tell me 'it can't be done' so I can forget it

Max M. · Jan 19, 2009, 12:13 AM

Well, the answer is yes, it is possible...
Not with FFT, but it is always can be done via just a network of bandpass filters (well, the RME does this via bandpasses too)
So the question is just how many bands it can have - approximately one band will need about 6 instructions and 5-6 registers - e.g (not counting any other code in DSP) ~80 bands for K2 - more then enough)

>I'd make a guess and say some sort of FFT and I know this has been said to be inpractical to do in DSP in most cases

for the fx8010 - it is kinda impossible - not really "inpractical"

TheKezReturns · Jan 19, 2009, 01:51 AM

Cheers for that Max. A series of bandpass filters sounds alot simpler.
Doesn't sound like it would be that difficult, for someone who knows their way around microcode that is...which I don't.

I have to admit, I haven't the faintest idea how digital filters work, especially in 10kx microcode, but I assume you would just need to figure out the coefficients for the individual bands, take a peak reading for each and send the data to the gui.
And possible store the values for rms and meter falling... or perhaps that would be better in the gui.

Would there need to be some trickery to get the slope of the filters steep enough?

Max M. · Jan 19, 2009, 03:52 AM

Well, i can do the DSP part of this in a weekend (that would be fun for me)
So if someone would volunteer for the GUI...

>Would there need to be some trickery to get the slope of the filters steep enough?

no, no trickery there - a conventional second-order bandpass can have whatever steep needed.

TheKezReturns · Jan 19, 2009, 08:31 AM

Quote:

Well, i can do the DSP part of this in a weekend (that would be fun for me)

Awesome.

I'd certainly contribute what I can to the GUI but I'd probably need some help.
I can definately do the graphics, and I've made a vst plugin before with a GUI in visual c++, but the VST SDK made that relatively easy. I'll have a look at the KX sdk and examples... see if I'm up to it.

Also, generally I find the lower half of the spectrum most helpful as a visual aid. It would be great to have a button that zooms in on the 20Hz to 1k range. I guess you'd just need a second set of coeffients. Do you thnk that would be doable?

Max M. · Jan 19, 2009, 08:43 AM

Ok then, i'm on it.

Well, as a starting point the GUI implementation could be very similiar to what the Peak plugins are doing (pretty same code) - and then extendend to whatever features will be handy.

>It would be great to have a button that zooms in on the 20Hz to 1k range. Would that be doable?

I think yes.

Maddogg6 · Jan 19, 2009, 05:24 PM

Just spitting out 'cool features' with out knowing how difficult - and certainly is not any expectation of any sort.....

If the coefficients are stored in an array...it could maybe be simple enough to allow users to specify a (zoom??) range - dictated by Sliders or something.
Ex:

CoeficientsToLoad(sliderAvalue) to CoeficientsToLoad(sliderBValue)

... maybe, to save on some resources, instead of using 1 big resource hog of a plugin - maybe split it up into multiple instances of the same plugin, with user specified ranges/zoom...say using 4 to cover 20-20Khz (or what ever) - but I may only need 1 instance to cover the 20-1K range....

Sort of thing. I dunno - I think could be useful for maybe a larger audience...

Again, just an idea.

TheKezReturns · Jan 19, 2009, 06:43 PM

Or just make three different versions.. say... 15 band, 30 band and 60 band.

Perhaps we could start with working 30 band, inspired by the rme digicheck, then adapt a couple of other versions or add a "number of bands' switch/slider in a later version.

Here's a shot of the rme one. Probably a good set of frequencies to start with.

Max M. · Jan 23, 2009, 04:32 PM

OK then, here we are: sa.zip
I decided to start with a 40 band thing.
The archive contains the dsp source code ("sa.da", "the SA" further) and c++ header with some definitions you'll optionally need (specifically, the corresponding band frequency values).
As i mentioned earlier, the kxl code can be the same as a Peak plugin code - except that you have 40 bands instead of two - so one could start just with copy-pasting of kX's peak sources (although, i'd suggest you to consider the source code of the "mx6" ("mx6" version in the kX SDK will fit) as its "peak" related code is much more readable than native kX's "peak" sources).

The only important difference between the "SA" and standard "Peak" plugins code is that the "SA" produces a 6dB higher peak values (so you will need to offset the visual representation accordingly).

The peak values of the "SA" are in pk00..pk39 registers, they are indexed continuously so to read the values in the plugin code (that's what one typically does on timer) you do a simple iteration - something like this:

Code:

void readPeaks(unsigned (&values)[sa::nBands])
{
    enum {pk00 = 0x8000}; // index of the first "peak" register (as in generated "SA_info")
    for (int i = 0; i < sa::nBands; i++)
    {
        get_dsp_register(word(pk00 + i), values + i);
        set_dsp_register(word(pk00 + i), 0);
    }
}

That's it, current peak values are in the "values" array - and the rest is a matter of drawing.
(well, strictly speaking, the kxl also should handle/apply all those "hold", "release/decay" features)

For a compatibility with the standard Peak plugins i made the "SA" to output the peak levels in logarithmic scale, but, as things go further, i'd suggest to switch to linear mode as it is a bit more flexible (see Peak plugin with one register less for a "lin.vs.log" peak handling overview)
To switch the "SA" to linear mode simply change (in "sa.da") "const plog = 31i" to "const plog = 1i".

OK... i think that's all for now - i'll post if i remember something important.

Ah, btw...
Known "SA" dsp code issues:

* Under some circumstances, the lowest 2 or 3 bands may produce a random noise about (up to) -70dB. (Basically, their frequency range is just where 32-bit precision is already not enough) - this is acceptable as a working range of a conventional spectrum analyzer is typically above that level (e.g. the noise won't be visible) - but (if necessary) the plugin (e.g. kxl) can have some workaround for noisy bands, for example it can ignore the values below ~-70dB (e.g. just threat it as -Inf.) or a sort of.

TheKezReturns · Jan 23, 2009, 06:48 PM

You da man Max. You don't mess around!
Ok, I'll dig out my old version of visual c++ see what damage I can do.
It will probably take me a while to get my head around it again. The last time I even looked at coed was about 6 years ago!
On that point, if anyone thinks they can knock it off in a few hours, don't let me stop you!

Max M. · Jan 27, 2009, 08:42 AM

For the proof of concept i've sketched a "minimalistic skeleton" plugin for the SA. "Minimalistic" is in quotes as in fact it is a full-featured spectrum analyzer with all of typical options/settings inside, however it does not provide any GUI to edit these options (it does not also have some other minor and boring features that a "production" plugin would have). This is just where i stop.

source code
kxl binary
screenshot

The binary is provided only for an evaluation purpose (though its use permission is not restricted specifically).
Regarding the sources, the only file of interest there is the sa.h header, it is where everything actually happens. A code in other files just provides an auxiliary functionality (common kxl handshaking, OS interaction and other boring stuff).

--------------------------
Performance considerations:

* Drawing.
The drawing code (which is the CPU load master for the concept) of the presented skeleton (a "Demo Library" if it makes sense) is not optimized at all (it uses the "slow" gdiplus, lotsa transparency and other fancy stuff, neither i used any of common drawing optimizations which would negatively affect the readability of the sources (this was a goal a sort of). Anyway the resulting CPU load of the plugin is not that bad - more then acceptable for an evaluation.

* Reading/writing dsp registers.
Though the bottleneck of the SA performance is its drawing (no matter how optimized it is), the amount of DSP read/write function calls (we have 80 per each update) causes some anxiety. Since each 'get/set_dsp_...' call is "the driver call" actually, it causes the OS to switch the user/kernel mode there and back (and this is not really a free of charge procedure). The concern is that such OS and driver tugging may negatively affect some critical driver operations (low-latency ASIO streaming for example). So at some point we'd probably like to see the kX SDK providing a function to read (and optionally write) an array of registers. It's not that the new function will really improve the SA performance (its DSP I/O related CPU load is nothing if compared to the drawing) or (vastly improve) it's I/O timing (as i understand the PCI bus and a hardware itself are the bottlenecks of the driver I/O) but likely it would help to get things a bit more smoothly or a sort of. Well, anyway, the new function won't make things worse by any means.

-------------------------
Building:
* Add the "h" directory of the kX SDK to include directories
* Add the "lib" directory of the kX SDK to library directories
* Link to kxapi.lib and gdiplus.lib
* Compile as non-MFC and non-unicode dll

Russ · Jan 27, 2009, 11:24 AM

Looks good Max.

Thanks for making the window sizeable (since it uses less CPU with smaller window).

Now if it just remembered it's size, and had an always on top option.

Max M. · Jan 27, 2009, 11:35 AM

>Now if it just remembered it's size, and had an always on top option.

yeah - this is what i meant with "minor and boring features that a "production" plugin would have"

Well, to be honest i have an update under development - so...

Maddogg6 · Jan 27, 2009, 11:37 AM

Very nice - I can even load it with the default DSP (10K2 anyway), something I did not expect.

your skills amaze me. Thank you very much.

TravelRec. · Jan 29, 2009, 07:38 AM

Hello Max M.,

thank you for the great and useful tool. It is a fine plugin that expands kX-drivers possibilities one more time

stylus02 · Feb 2, 2009, 08:32 AM

excellent max, great mastering tool.

edwardar · Feb 2, 2009, 02:40 PM

I just wanted to thank you too for this - it's amazing what these old soundcards are capable of - what's more amazing is the skill and time put in by the coders of some of these fantastic plugins!

Max M. · Feb 7, 2009, 09:59 PM

Meanwhile i have updated the SA.minus.

Changes:
* Settings are now editable via keyboard shortcuts (press F1 for the list)
* Display colours are editable via registry (i included several colour schemes for show, but you can craft your own and share it with others)
* Some cosmetic drawing optimizations (~1.5 times faster with default settings)
* Other boring stuff here and there (saving window size and position etc. etc.)

source code
kxl binary
screenshot

Since current kxl source code is a bit cryptic in certain aspects (i'm just lazy to clean it up) - i'll keep the sources of the vanilla kxl available for reference.

Russ · Feb 7, 2009, 11:17 PM

Nice Max, thanks again

The "Change peak hold representation (bar/line)" option (among other things) is a nice touch

A note to anyone who might be using my PluginQL addon, this plugin uses one of the same key combos as does PluginQL, and as such you will need to disable the hotkeys in PluginQL in order to save settings in this plugin.

TheKezReturns · Feb 9, 2009, 09:04 AM

Max you're a star. Many thanks for your effort.

Maddogg6 · Feb 9, 2009, 03:11 PM

Yes... very nice Max.... to celebrate I made a color scheme I called 'Graphite'...

Code:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\kX\Plugins\SA.minus\Colours\Graphite]
"peakBarColor"=dword:cc606060
"holdBarColor"=dword:ffcccccc
"bkgLightColor"=dword:00333333
"bkgDarkColor"=dword:00000000
"gridBorderColor"=dword:ff000000
"gridLineColor"=dword:ff606060
"labelColor"=dword:ff999999

Instructions...
Save in MS Notepad - save as Graphite.reg - dbl click to register the resistry file...

stylus02 · Feb 9, 2009, 03:36 PM

wow, the update looks highly professional! my favorites: peak hold line & black/yellow color scheme. wonderful...

Max M. · Feb 9, 2009, 04:26 PM

btw. i almost forgot: there's 'undocumented' F5 shortcut - this command reloads current scheme color values from registry. It's obviously useful when making a new colour scheme (e.g. you can see the changes you make in registry on the fly - e.g. modify color value -> F5 -> see result)

stylus02 · Feb 10, 2009, 08:52 AM

max, i had fun while using your "secret f5- option". here is my setup for a fluke- like analyser.

1. doubleklick the *.reg's to register preset (one for color scheme,
the other one for settings)

2. be shure to load settings from slot 9 (strg + 9) !

tip: if your level is to low, use a gain plugin before the "sa.minus".
also my "kxm 160" (4 x multiplier) can do this.

http://freenet-homepage.de/stylish-s...inus_fluke.zip
http://freenet-homepage.de/stylish-s...inus_fluke.jpg

stylus

Max M. · Feb 10, 2009, 09:18 AM

oh, cool looking schemes, thanks guys!

>tip: if your level is to low, use a gain plugin before the "sa.minus".

i guess this tip applies only to *really* too low levels (<-40...-50dB?), does it? - as in other cases you're supposed only to decrease the top value of the level display range within SA: "Shift + Up Arrow" (maybe i just wrote a poor desription for that command)

stylus02 · Feb 10, 2009, 09:56 AM

yes, my overall level is a bit low, so i gave it more gain to reach 0 db. this gaining isn't tragically, because i mainly want compare frequencies.
of course i have read your documentation very well and used all these nice options.

edit: made some testtones with soundforge 5.0: 100 hz, 1khz, 10 khz, sinoid, normalized to 0 db, 16 bit, mono. in "sa.minus" the 1khz tone reaches ~ 0db, the other ones only ~ -3db. why this happens? (at first i was wondering about the bassdrum- level, which was to low in my opinion). i tested it on a ct4620 10k1, driver 3545.

the results:
http://freenet-homepage.de/stylish-s...s_sa.minus.jpg
http://freenet-homepage.de/stylish-s...nes_sinoid.mp3

stylus

Max M. · Feb 10, 2009, 12:55 PM

It's just a property of a "band-based" analyzer - we have only 40 points of exact level matches and any frequency laying in between these band points give you the peak that below the real peak down to -6dB. This property simply comes out of its "band" basis (peak level of each "band" is simply a peak of the output of the corresponding band-pass filter).
In your case it's only the 1kHz sine that hits the band center, while others are laying in between bands (for example 100Hz frequency is in the middle of ~88.4 and ~105Hz bands).
This is a "natural" band-based analyzer disadvantage if compared to "FFT-based" one (you have much more points with FFT typically).

There's curious example of this property/limitation:
for this display - there's absolutely no way to find out if it is either a single 0dB sinewave at 545.25Hz or two sinewaves with -6dB level at 500 and 594.6Hz

Maddogg6 · Feb 10, 2009, 01:13 PM

Quote:

edit: made some testtones with soundforge 5.0: 100 hz, 1khz, 10 khz, sinoid, normalized to 0 db, 16 bit, mono. in "sa.minus" the 1khz tone reaches ~ 0db, the other ones only ~ -3db. why this happens? (at first i was wondering about the bassdrum- level, which was to low in my opinion). i tested it on a ct4620 10k1, driver 3545.

Did some testing too... I compared SA.Minus to Peak levels using Wave Generator 3.
And indeed levels seems to be represented about 3 db (maybe 2.5 db) lower in SA.Minus compared to PEAK for freq's < 200 Hz. and Above 4Khz. While Peak stayed at a constant 0db.

Not only that, when I tweak Wave Gens FREQ control - the whole display jumps - it is likely from the needed simplified filters to fit in a DSP plugin of this nature.... So, I am not complaining, its not really a problem for me at all... just un-expected behavior that, as long as I know, is not a big deal. Not like I am mastering a $1M record production for a big studio or anything

I think its just the nature of this beast. I suppose a EQ could be used to compensate for this 'roll off'. I dunno...

Edit: Damn I took too long to write this... /edit

Max M. · Feb 10, 2009, 01:44 PM

well, just to avoid confisuion (sure no complaining at all

- we just share the info) - there's no rolloff (you get your "-2..3dB" results just because you set the WaveGen to the frequencies that are natural to human eye (like 100Hz or 5Hz or 10Khz) but they're just fall out of the SA band points (its freq points are 1/4 octave points with anchor at 1kHz)
Try this test to see the rolloff

- better to test with increased peak hold time.

Jan 17, 2009, 09:01 PM	#1
TheKezReturns DriverHeaven Lover Join Date: Apr 2005 Location: Gold Coast Australia Posts: 115 Rep Power: 28	Spectrum analyzer possible in DSP? I was in a guys studio the other week and he had the realtime spectrum analyzer from his RME interface running permananetly on a second monitor. It's part of the driver and runs independantly of asio hosts ect. This is great for cross refernecing against mp3s ect and having to insert a vst plugin on the master and every time and work a way to get it visible permanently just isn't the same. Also, this one could almost fill the whoile screen. I've even heard of people running a whole spare PC just for this..... A KX Dsp plugins would be much neater. I'm not sure how they work. I'd make a guess and say some sort of FFT and I know this has been said to be inpractical to do in DSP in most cases, but considering it just has to break the frequency bands up and display them, could it be done? Obvisuly, sound quality isn't an issue and there's no processing or recombining of the bands to deal with. As far as resources, I'd be happy if the DSP was devoted to one really useful thing, considering everything else is better in vst plugin form these days anyway. __________________ Dual Boot Hacky XP / OSX /Ubuntu. 2.13 C2D. 4 Gb DDR2. Intel DG965RY. EMU 1820M / TC Konnekt 24D / MOTU Ultralite mk3

Jan 18, 2009, 07:04 PM	#2
TheKezReturns DriverHeaven Lover Join Date: Apr 2005 Location: Gold Coast Australia Posts: 115 Rep Power: 28	Re: Spectrum analyzer possible in DSP? This was brought up once before but nailed quickly with a 'just use this expensive software' kinda answer. But a dedicated, non cpu intensive, permanently running analyzer thats monotoring everythig that comes out the main outputs is really what I'm hoping for. Someone just tell me 'it can't be done' so I can forget it __________________ Dual Boot Hacky XP / OSX /Ubuntu. 2.13 C2D. 4 Gb DDR2. Intel DG965RY. EMU 1820M / TC Konnekt 24D / MOTU Ultralite mk3

Jan 19, 2009, 12:13 AM	#3
Max M. d/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,412 Rep Power: 47	Îòâåò: Spectrum analyzer possible in DSP? Well, the answer is yes, it is possible... Not with FFT, but it is always can be done via just a network of bandpass filters (well, the RME does this via bandpasses too) So the question is just how many bands it can have - approximately one band will need about 6 instructions and 5-6 registers - e.g (not counting any other code in DSP) ~80 bands for K2 - more then enough) >I'd make a guess and say some sort of FFT and I know this has been said to be inpractical to do in DSP in most cases for the fx8010 - it is kinda impossible - not really "inpractical" __________________

Jan 19, 2009, 01:51 AM	#4
TheKezReturns DriverHeaven Lover Join Date: Apr 2005 Location: Gold Coast Australia Posts: 115 Rep Power: 28	Re: Spectrum analyzer possible in DSP? Cheers for that Max. A series of bandpass filters sounds alot simpler. Doesn't sound like it would be that difficult, for someone who knows their way around microcode that is...which I don't. I have to admit, I haven't the faintest idea how digital filters work, especially in 10kx microcode, but I assume you would just need to figure out the coefficients for the individual bands, take a peak reading for each and send the data to the gui. And possible store the values for rms and meter falling... or perhaps that would be better in the gui. Would there need to be some trickery to get the slope of the filters steep enough? __________________ Dual Boot Hacky XP / OSX /Ubuntu. 2.13 C2D. 4 Gb DDR2. Intel DG965RY. EMU 1820M / TC Konnekt 24D / MOTU Ultralite mk3

Jan 19, 2009, 03:52 AM	#5
Max M. d/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,412 Rep Power: 47	Îòâåò: Spectrum analyzer possible in DSP? Well, i can do the DSP part of this in a weekend (that would be fun for me) So if someone would volunteer for the GUI... >Would there need to be some trickery to get the slope of the filters steep enough? no, no trickery there - a conventional second-order bandpass can have whatever steep needed. __________________

Jan 19, 2009, 08:43 AM	#7
Max M. d/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,412 Rep Power: 47	Îòâåò: Spectrum analyzer possible in DSP? Ok then, i'm on it. Well, as a starting point the GUI implementation could be very similiar to what the Peak plugins are doing (pretty same code) - and then extendend to whatever features will be handy. >It would be great to have a button that zooms in on the 20Hz to 1k range. Would that be doable? I think yes. __________________ Last edited by Max M.; Jan 19, 2009 at 08:49 AM.

Jan 19, 2009, 05:24 PM	#8
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 36	Re: Spectrum analyzer possible in DSP? Just spitting out 'cool features' with out knowing how difficult - and certainly is not any expectation of any sort..... If the coefficients are stored in an array...it could maybe be simple enough to allow users to specify a (zoom??) range - dictated by Sliders or something. Ex: CoeficientsToLoad(sliderAvalue) to CoeficientsToLoad(sliderBValue) ... maybe, to save on some resources, instead of using 1 big resource hog of a plugin - maybe split it up into multiple instances of the same plugin, with user specified ranges/zoom...say using 4 to cover 20-20Khz (or what ever) - but I may only need 1 instance to cover the 20-1K range.... Sort of thing. I dunno - I think could be useful for maybe a larger audience... Again, just an idea.

Jan 19, 2009, 06:43 PM	#9
TheKezReturns DriverHeaven Lover Join Date: Apr 2005 Location: Gold Coast Australia Posts: 115 Rep Power: 28	Re: Spectrum analyzer possible in DSP? Or just make three different versions.. say... 15 band, 30 band and 60 band. Perhaps we could start with working 30 band, inspired by the rme digicheck, then adapt a couple of other versions or add a "number of bands' switch/slider in a later version. Here's a shot of the rme one. Probably a good set of frequencies to start with. Attached Images __________________ Dual Boot Hacky XP / OSX /Ubuntu. 2.13 C2D. 4 Gb DDR2. Intel DG965RY. EMU 1820M / TC Konnekt 24D / MOTU Ultralite mk3

Jan 23, 2009, 04:32 PM	#10
Max M. d/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,412 Rep Power: 47	Îòâåò: Spectrum analyzer possible in DSP? OK then, here we are: sa.zip I decided to start with a 40 band thing. The archive contains the dsp source code ("sa.da", "the SA" further) and c++ header with some definitions you'll optionally need (specifically, the corresponding band frequency values). As i mentioned earlier, the kxl code can be the same as a Peak plugin code - except that you have 40 bands instead of two - so one could start just with copy-pasting of kX's peak sources (although, i'd suggest you to consider the source code of the "mx6" ("mx6" version in the kX SDK will fit) as its "peak" related code is much more readable than native kX's "peak" sources). The only important difference between the "SA" and standard "Peak" plugins code is that the "SA" produces a 6dB higher peak values (so you will need to offset the visual representation accordingly). The peak values of the "SA" are in pk00..pk39 registers, they are indexed continuously so to read the values in the plugin code (that's what one typically does on timer) you do a simple iteration - something like this: Code: void readPeaks(unsigned (&values)[sa::nBands]) { enum {pk00 = 0x8000}; // index of the first "peak" register (as in generated "SA_info") for (int i = 0; i < sa::nBands; i++) { get_dsp_register(word(pk00 + i), values + i); set_dsp_register(word(pk00 + i), 0); } } That's it, current peak values are in the "values" array - and the rest is a matter of drawing. (well, strictly speaking, the kxl also should handle/apply all those "hold", "release/decay" features) For a compatibility with the standard Peak plugins i made the "SA" to output the peak levels in logarithmic scale, but, as things go further, i'd suggest to switch to linear mode as it is a bit more flexible (see Peak plugin with one register less for a "lin.vs.log" peak handling overview) To switch the "SA" to linear mode simply change (in "sa.da") "const plog = 31i" to "const plog = 1i". OK... i think that's all for now - i'll post if i remember something important. Ah, btw... Known "SA" dsp code issues: * Under some circumstances, the lowest 2 or 3 bands may produce a random noise about (up to) -70dB. (Basically, their frequency range is just where 32-bit precision is already not enough) - this is acceptable as a working range of a conventional spectrum analyzer is typically above that level (e.g. the noise won't be visible) - but (if necessary) the plugin (e.g. kxl) can have some workaround for noisy bands, for example it can ignore the values below ~-70dB (e.g. just threat it as -Inf.) or a sort of. __________________ Last edited by Max M.; Jan 23, 2009 at 04:40 PM.

Jan 23, 2009, 06:48 PM	#11
TheKezReturns DriverHeaven Lover Join Date: Apr 2005 Location: Gold Coast Australia Posts: 115 Rep Power: 28	Re: Spectrum analyzer possible in DSP? You da man Max. You don't mess around! Ok, I'll dig out my old version of visual c++ see what damage I can do. It will probably take me a while to get my head around it again. The last time I even looked at coed was about 6 years ago! On that point, if anyone thinks they can knock it off in a few hours, don't let me stop you! __________________ Dual Boot Hacky XP / OSX /Ubuntu. 2.13 C2D. 4 Gb DDR2. Intel DG965RY. EMU 1820M / TC Konnekt 24D / MOTU Ultralite mk3

Jan 27, 2009, 08:42 AM	#12
Max M. d/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,412 Rep Power: 47	Îòâåò: Spectrum analyzer possible in DSP? For the proof of concept i've sketched a "minimalistic skeleton" plugin for the SA. "Minimalistic" is in quotes as in fact it is a full-featured spectrum analyzer with all of typical options/settings inside, however it does not provide any GUI to edit these options (it does not also have some other minor and boring features that a "production" plugin would have). This is just where i stop. source code kxl binary screenshot The binary is provided only for an evaluation purpose (though its use permission is not restricted specifically). Regarding the sources, the only file of interest there is the sa.h header, it is where everything actually happens. A code in other files just provides an auxiliary functionality (common kxl handshaking, OS interaction and other boring stuff). -------------------------- Performance considerations: * Drawing. The drawing code (which is the CPU load master for the concept) of the presented skeleton (a "Demo Library" if it makes sense) is not optimized at all (it uses the "slow" gdiplus, lotsa transparency and other fancy stuff, neither i used any of common drawing optimizations which would negatively affect the readability of the sources (this was a goal a sort of). Anyway the resulting CPU load of the plugin is not that bad - more then acceptable for an evaluation. * Reading/writing dsp registers. Though the bottleneck of the SA performance is its drawing (no matter how optimized it is), the amount of DSP read/write function calls (we have 80 per each update) causes some anxiety. Since each 'get/set_dsp_...' call is "the driver call" actually, it causes the OS to switch the user/kernel mode there and back (and this is not really a free of charge procedure). The concern is that such OS and driver tugging may negatively affect some critical driver operations (low-latency ASIO streaming for example). So at some point we'd probably like to see the kX SDK providing a function to read (and optionally write) an array of registers. It's not that the new function will really improve the SA performance (its DSP I/O related CPU load is nothing if compared to the drawing) or (vastly improve) it's I/O timing (as i understand the PCI bus and a hardware itself are the bottlenecks of the driver I/O) but likely it would help to get things a bit more smoothly or a sort of. Well, anyway, the new function won't make things worse by any means. ------------------------- Building: * Add the "h" directory of the kX SDK to include directories * Add the "lib" directory of the kX SDK to library directories * Link to kxapi.lib and gdiplus.lib * Compile as non-MFC and non-unicode dll __________________ Last edited by Max M.; Feb 7, 2009 at 09:38 PM.

Jan 27, 2009, 11:24 AM	#13
Russ DriverHeaven Extreme Member Join Date: Jan 2005 Posts: 4,836 Rep Power: 41	Re: Spectrum analyzer possible in DSP? Looks good Max. Thanks for making the window sizeable (since it uses less CPU with smaller window). Now if it just remembered it's size, and had an always on top option.

Jan 27, 2009, 11:35 AM	#14
Max M. d/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,412 Rep Power: 47	Îòâåò: Spectrum analyzer possible in DSP? >Now if it just remembered it's size, and had an always on top option. yeah - this is what i meant with "minor and boring features that a "production" plugin would have" Well, to be honest i have an update under development - so... __________________

Jan 27, 2009, 11:37 AM	#15
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 36	Re: Spectrum analyzer possible in DSP? Very nice - I can even load it with the default DSP (10K2 anyway), something I did not expect. your skills amaze me. Thank you very much.

Jan 29, 2009, 07:38 AM	#16
TravelRec. Alternative Audioproductions Join Date: Sep 2003 Location: Germany / Sachsen-Anhalt Posts: 1,704 Rep Power: 42	Re: Spectrum analyzer possible in DSP? Hello Max M., thank you for the great and useful tool. It is a fine plugin that expands kX-drivers possibilities one more time __________________ Always take a look behind.

Feb 2, 2009, 08:32 AM	#17
stylus02 DriverHeaven Lover Join Date: Jan 2008 Location: germany, sb0090 Posts: 158 Rep Power: 0	Re: Spectrum analyzer possible in DSP? excellent max, great mastering tool. __________________ http://freenet-homepage.de/stylish-s...xas/index.html

Feb 2, 2009, 02:40 PM	#18
edwardar DriverHeaven Junior Member Join Date: Jan 2003 Posts: 30 Rep Power: 0	Re: Spectrum analyzer possible in DSP? I just wanted to thank you too for this - it's amazing what these old soundcards are capable of - what's more amazing is the skill and time put in by the coders of some of these fantastic plugins!

Feb 7, 2009, 09:59 PM	#19
Max M. d/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,412 Rep Power: 47	SA.minus updated Meanwhile i have updated the SA.minus. Changes: * Settings are now editable via keyboard shortcuts (press F1 for the list) * Display colours are editable via registry (i included several colour schemes for show, but you can craft your own and share it with others) * Some cosmetic drawing optimizations (~1.5 times faster with default settings) * Other boring stuff here and there (saving window size and position etc. etc.) source code kxl binary screenshot Since current kxl source code is a bit cryptic in certain aspects (i'm just lazy to clean it up) - i'll keep the sources of the vanilla kxl available for reference. __________________ Last edited by Max M.; Feb 7, 2009 at 10:06 PM.

Feb 7, 2009, 11:17 PM	#20
Russ DriverHeaven Extreme Member Join Date: Jan 2005 Posts: 4,836 Rep Power: 41	Re: Spectrum analyzer possible in DSP? Nice Max, thanks again The "Change peak hold representation (bar/line)" option (among other things) is a nice touch A note to anyone who might be using my PluginQL addon, this plugin uses one of the same key combos as does PluginQL, and as such you will need to disable the hotkeys in PluginQL in order to save settings in this plugin. Last edited by Russ; Feb 7, 2009 at 11:46 PM.

Feb 9, 2009, 09:04 AM	#21
TheKezReturns DriverHeaven Lover Join Date: Apr 2005 Location: Gold Coast Australia Posts: 115 Rep Power: 28	Re: Spectrum analyzer possible in DSP? Max you're a star. Many thanks for your effort. __________________ Dual Boot Hacky XP / OSX /Ubuntu. 2.13 C2D. 4 Gb DDR2. Intel DG965RY. EMU 1820M / TC Konnekt 24D / MOTU Ultralite mk3

Feb 9, 2009, 03:11 PM	#22
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 36	Re: Spectrum analyzer possible in DSP? Yes... very nice Max.... to celebrate I made a color scheme I called 'Graphite'... Code: Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\kX\Plugins\SA.minus\Colours\Graphite] "peakBarColor"=dword:cc606060 "holdBarColor"=dword:ffcccccc "bkgLightColor"=dword:00333333 "bkgDarkColor"=dword:00000000 "gridBorderColor"=dword:ff000000 "gridLineColor"=dword:ff606060 "labelColor"=dword:ff999999 Instructions... Save in MS Notepad - save as Graphite.reg - dbl click to register the resistry file...

Feb 9, 2009, 03:36 PM	#23
stylus02 DriverHeaven Lover Join Date: Jan 2008 Location: germany, sb0090 Posts: 158 Rep Power: 0	Re: Spectrum analyzer possible in DSP? wow, the update looks highly professional! my favorites: peak hold line & black/yellow color scheme. wonderful... __________________ http://freenet-homepage.de/stylish-s...xas/index.html

Feb 9, 2009, 04:26 PM	#24
Max M. d/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,412 Rep Power: 47	Îòâåò: Spectrum analyzer possible in DSP? btw. i almost forgot: there's 'undocumented' F5 shortcut - this command reloads current scheme color values from registry. It's obviously useful when making a new colour scheme (e.g. you can see the changes you make in registry on the fly - e.g. modify color value -> F5 -> see result) __________________

Feb 10, 2009, 08:52 AM	#25
stylus02 DriverHeaven Lover Join Date: Jan 2008 Location: germany, sb0090 Posts: 158 Rep Power: 0	Re: Spectrum analyzer possible in DSP? max, i had fun while using your "secret f5- option". here is my setup for a fluke- like analyser. 1. doubleklick the *.reg's to register preset (one for color scheme, the other one for settings) 2. be shure to load settings from slot 9 (strg + 9) ! tip: if your level is to low, use a gain plugin before the "sa.minus". also my "kxm 160" (4 x multiplier) can do this. http://freenet-homepage.de/stylish-s...inus_fluke.zip http://freenet-homepage.de/stylish-s...inus_fluke.jpg stylus __________________ http://freenet-homepage.de/stylish-s...xas/index.html

Feb 10, 2009, 09:18 AM	#26
Max M. d/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,412 Rep Power: 47	Îòâåò: Spectrum analyzer possible in DSP? oh, cool looking schemes, thanks guys! >tip: if your level is to low, use a gain plugin before the "sa.minus". i guess this tip applies only to really too low levels (<-40...-50dB?), does it? - as in other cases you're supposed only to decrease the top value of the level display range within SA: "Shift + Up Arrow" (maybe i just wrote a poor desription for that command) __________________ Last edited by Max M.; Feb 10, 2009 at 09:37 AM. Reason: misprint

Feb 10, 2009, 09:56 AM	#27
stylus02 DriverHeaven Lover Join Date: Jan 2008 Location: germany, sb0090 Posts: 158 Rep Power: 0	Re: Îòâåò: Spectrum analyzer possible in DSP? yes, my overall level is a bit low, so i gave it more gain to reach 0 db. this gaining isn't tragically, because i mainly want compare frequencies. of course i have read your documentation very well and used all these nice options. edit: made some testtones with soundforge 5.0: 100 hz, 1khz, 10 khz, sinoid, normalized to 0 db, 16 bit, mono. in "sa.minus" the 1khz tone reaches ~ 0db, the other ones only ~ -3db. why this happens? (at first i was wondering about the bassdrum- level, which was to low in my opinion). i tested it on a ct4620 10k1, driver 3545. the results: http://freenet-homepage.de/stylish-s...s_sa.minus.jpg http://freenet-homepage.de/stylish-s...nes_sinoid.mp3 stylus __________________ http://freenet-homepage.de/stylish-s...xas/index.html Last edited by stylus02; Feb 10, 2009 at 12:05 PM.

Feb 10, 2009, 12:55 PM	#28
Max M. d/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,412 Rep Power: 47	Îòâåò: Spectrum analyzer possible in DSP? It's just a property of a "band-based" analyzer - we have only 40 points of exact level matches and any frequency laying in between these band points give you the peak that below the real peak down to -6dB. This property simply comes out of its "band" basis (peak level of each "band" is simply a peak of the output of the corresponding band-pass filter). In your case it's only the 1kHz sine that hits the band center, while others are laying in between bands (for example 100Hz frequency is in the middle of ~88.4 and ~105Hz bands). This is a "natural" band-based analyzer disadvantage if compared to "FFT-based" one (you have much more points with FFT typically). There's curious example of this property/limitation: for this display - there's absolutely no way to find out if it is either a single 0dB sinewave at 545.25Hz or two sinewaves with -6dB level at 500 and 594.6Hz __________________

Feb 10, 2009, 01:44 PM	#30
Max M. d/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,412 Rep Power: 47	Îòâåò: Spectrum analyzer possible in DSP? well, just to avoid confisuion (sure no complaining at all - we just share the info) - there's no rolloff (you get your "-2..3dB" results just because you set the WaveGen to the frequencies that are natural to human eye (like 100Hz or 5Hz or 10Khz) but they're just fall out of the SA band points (its freq points are 1/4 octave points with anchor at 1kHz) Try this test to see the rolloff - better to test with increased peak hold time. __________________

LinkBacks (?) LinkBack to this Thread: http://www.driverheaven.net/effects-dsp/176505-spectrum-analyzer-possible-dsp.html
Posted By	For	Type	Date
CQHAM.RU :: Ïðîñìîòð òåìû - Âûáîð çâóêîâîé êàðòû è äðàéâåðîâ äëÿ SDR.	This thread	Refback	Aug 4, 2009 02:28 PM
Ôîðóìû CQHAM.RU :: Ïðîñìîòð òåìû - Âûáîð çâóêîâîé êàðòû è äðàéâåðîâ äëÿ SDR.	This thread	Refback	May 22, 2009 06:31 AM
Ôîðóìû CQHAM.RU :: Ïðîñìîòð òåìû - Âûáîð çâóêîâîé êàðòû è äðàéâåðîâ äëÿ SDR.	This thread	Refback	May 22, 2009 03:30 AM
Ôîðóìû CQHAM.RU :: Ïðîñìîòð òåìû - Âûáîð çâóêîâîé êàðòû è äðàéâåðîâ äëÿ SDR.	This thread	Refback	May 22, 2009 03:29 AM
Ôîðóìû CQHAM.RU :: Ïðîñìîòð òåìû - Âûáîð çâóêîâîé êàðòû è äðàéâåðîâ äëÿ SDR.	This thread	Refback	May 22, 2009 03:23 AM

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Spectrum Analyzer in kX?	lowenz	General Discussion	55	Dec 5, 2004 07:43 PM
Spectrum info	ROBSCIX	General Discussion	3	Nov 3, 2004 04:05 AM
Full Spectrum Warrior! MUST SEE!	Warpy	Gaming Discussion	4	Sep 16, 2004 12:20 PM
Analyzer	mzry	General Discussion	1	Apr 28, 2004 04:21 PM
spectrum analyzer!	trance1meister	Effects and the DSP	2	Mar 9, 2003 09:00 PM