DSP Robotics Support

Drnkhobo wrote:Ive just noticed (yes,only now) when you connect a text primitive to the dsp module, it shows the conversion to asm right?
- Also why not then just use the output and have a asm instead of dsp module???

Yes, it is the assembly output of the compiler. - and yes, you can copy and paste it into an assembly primitive.
If you just do that, there is no radvantage, as the instructions used by the CPU will remain exactly the same, as DSP code is compiled rather than interpreted. However, once you have your code nice and tight, the assembly listing gives you a starting point for optimising it further.
The code compiler is really quite basic, and often puts extra opcodes in there that aren't really needed - for example writing a register value (the xmm's) to memory, and then immediately reading it back out again - like this...

...and then there a million and one other things that you can do to eat away at the CPU cycles. It really is a huge subject to learn (and very addictive!) - I have seen some code designs reduced to less than 20% of the CPU load using hand written assembly, though the savings are only very rarely that big.
However, the best advice is to get to know the DSP code really well first - unless the code program is already very well optimised, there is little point in saving just a few CPU cycles with assembly. It is also very tricky to do, as assembly is very hard to read, there are no de-bugging tools, and it's very easy to make crashes!
However, if you do want to start learning a little assembly,, making little codes and then peeking at the compiler output is a damn good way to start.
You can also learn to write better code by looking at the assembly - you can find ways to write your code statements that make the assembly listing shorter. From the RMS code, a good example would be the min/max part. It will come out with less memory read/writes if you write it all on one line, i.e....

I thought so!

Ill be spending some time checking how the asm code works! I found some assembly language resources but I don't think its exactly the same, I dunno....

Anyway, I seem to be stumped again. Little further down the chain this time.Im trying to get my auto gain module to be accurate, but it seems after it has to increase the signal by more than 50db, it gets ugly . . . What ?

So im using my rms code as optimized before and i have a simple module, input amp, another amp and finally a output amp. So i take a reading from the input amp (lin1) and one from the second amp (lin2);

Then I divide lin1 by lin2 and attenuate . . .

But as I said before, when it has to make up for more than 50 db, it starts to get inaccurate.
Why?

Also, im ashamed to say, im getting worrying results from my tests with a compressor.

Ive made a really simple compressor and tested it with a FFT .

So in the pics the RED signal is WET (running through the comp)
And the BLACK is the DRY (dry like a bone)





As you can see from the results, on one hand it is attenuating frequencies that I dont want it to, PIC1- Its dry here so should NOT be attenuating. On the other hand its introducing freq spikes when ratio is active.

Ive made the compressor clean as possible. That I could think, here is how it flows. . .

IN--(abs)--(lin2dB)--(Gain Reduction)--(Envelope)--(dB2lin)--(VCA)--OUT

So my VCA is attenuating the dry signal.


Anyone had a similar problem?

Drnkhobo wrote:I found some assembly language resources but I don't think its exactly the same, I dunno...

The assembly commands are pretty much universal to all PC's these days, so descriptions of the opcodes that you find online will be accurate - but there is a catch!
FS only supports a small sub-set of the assembly commands, mostly ones that are part of the original generation of SSE.
This wasn't done just to annoy us! - it is to make sure that the assembly we make will be compatible with the other parts of an FS schematic. In particular, it is essential so that mono4 and polyphonic streams work OK, as they rely very much on SSE to reduce the amount of CPU that is needed for handling multiple audio streams.
Apart from a few references here and there, all of the assembly that I've learned has come from guys on the SM forums, and just messing with schematics - and this is maybe the best way to do it, as trying to learn assembly from other places is kind of tricky - Catch-22, you don't know which parts will apply to FS until you have already learned them, and most assembly 'courses' would leave the SSE stuff until quite far into the course.

Drnkhobo wrote:Then I divide lin1 by lin2 and attenuate

If your input levels, and GR/output gain are calibrated in dB then you should be subtracting, not dividing!
If you did it without dB conversion, then dividing would be appropriate (though calibrating everything might be much harder). Once things are in dB, you are in the land of logarithms and raising to powers; for example...
(10 ^ 2) * (10 ^ 2) = 10,000 = 10 ^ (2+2)
dB values represent how much raising to a power is needed to make one signal match another (like the '2's in this example) - so adding and subtracting dB's is equivalent to scaling in 'absolute' values.

That doesn't necessarily explain the frequency differences though - unless you have filters in there, the gain should be the same at all frequencies. Without seeing your schematic, it is hard to know exactly why this is - but here are my top two guesses...
1 - The sound at that frequency is just too loud, and overloading the FFT. Off-the-scale a lot and off-the-scale a little bit are just off-the-scale full stop - so the peaks would look the same even if one really is quieter than the other. Could be a side-effect of dividing the dB numbers.
2 - The Attack and Release are way too short. Once they get very small, the attack and release start to track the individual peaks of the sound waves, and this can make the envelope start to behave like a filter. This problem will be worse if the input level detectors also use a very short averaging time.

The spikes are most likely aliasing distortion - which suggests that something is overloading somewhere. Again, this could easily just be the FFT being given a signal which is too 'hot'.

Best bet would be to upload your schematic - it is much easier to diagnose the problem when the design can be opened in FS for a poke around inside.

PS) Might be worth asking one of the admins/moderators if they could split this thread. The topic has changed rather a lot since the start. Compressors etc. are a popular thing to build, and it is easier to attract more helpers if the topic has a more appropriate title.

I feel like I should have a direct line to you Trog!

Thanks!

Assembly seems very laborious right now,like your previous example.So im gonna stick to mucking about with the dsp module and asm output. . .


My division isnt done in dB. Do you think it would be better? And yeah I would then subtract, example:

IN: -50dB
OUT: -10dB
So. . .
in(lin1) - out(lin2)
= -40dB


About the test, the signal I used was a square tone 440hz @ 0dB
So it could be riding hot but it was not clipping in Audition.
Ive capped the attack & rel speeds to 1ms-300ms.
I think they were around 10ms?????

- Ive asked admin to make a new thread

Hi again,

0dB might be a little hot still (for the FFT, not your schematic), and IMHO a 10ms release is rather fast - you'll almost certainly be getting a little bit of gain-riding on the individual cycles at 440Hz, which may explain those small frequency peaks on your FFT.

Had a quick look at the schematic you 'Dropboxed' - and I have to say, it looks very good. I stuck some tests into each module in turn, and your assembly is all working very well; nice job!
A couple of comments - though as you only showed a part of the schematic, this is maybe stuff that you have already sorted...
The one thing I would add is to return the 'averaging' to the detector - although the envelope generator will smooth the GR values, the dB section is unlikely to work properly unless it is given a good chunk of the waveform to average over.. As it is, the dB value will be bouncing up and down like a yo-yo, making life hard for the envelope - and this will lead to some modulation of the signal that might give you some distortion.
That will be even more important if you use it for an auto-gain feature - you really must compare the average levels of the two signals for that, as if you compare sample-by-sample, any effect that changes the phase of the signal (e.g. most filters), will result in a much bigger difference value than you would expect.

Thanks Trog

There's not much happening after that, except for the AG module.
But I have set it up so it checks for its rms value.

What do you mean "return the averaging to the detector"?
Are you saying add the db back into the rms in the beginning?
Or do you mean for the AG module?

And the meters are pretty stable with the dB as is.Maybe its cause they are on their own rms detections. In dB

Still getting those nasty freq spikes even with long attack & rel times

trogluddite wrote:Hi again,

The one thing I would add is to return the 'averaging' to the detector - although the envelope generator will smooth the GR values, the dB section is unlikely to work properly unless it is given a good chunk of the waveform to average over.. .

Hey Trog did you mean calculate the dB in a hop?
So it catches more of the sample?
Im trying to figure out what you meant but cant seem to get it with my example. . .

Do you mind explaining a bit more ?

Thanks