PWM compressor

[ruffrecords]

Just been looking at the Atmel SAM8X data sheet (as used in the Due). Looks like it has 32 bit PWM counters and the period and duty cycle are separately programmable. This means we can have any bit number of bits (and hence resolution)  we like in the PWM signal.

The clock section is enormously complex but it looks like a master clock (MCK) of 80MHz is possible and the PWM can use MCK directly. This would give us 9 bits of resolution at 100KHz or 8 bits at 200KHz. Just need to find out what value MCK actually is in the Due.

Cheers

Ian

 

[ruffrecords]

  Maybe some auto range could help, making adaptive to swap between 12dB range cell and 36dB range, just swapping a resistor in the cell. Then is the fact of when use one or the other, how and when to switch, etc. Better specs up to 12dB range, when you need to go further you probably are having other problems to be looking at.

JS

I am not sure that will be necessary. With 8 bits, giving a PWM 'value' from 256 down to zero, the first 128 values cover a 6dB range. The next 64 cover the next 6dB, the next 32 cover the next 6dB and the next 16 the next 6dB. So a 24dB range is covered by all but 16 'values'. Basically as the attenuation increases the attenuation resolution gets coarser.

Cheers

Ian

 

[joaquins]

  328 can do PWM up to 16 bits, check the manual in the timers/PWM section, it has various PWM modes, fast, phase correct and normal IIRC. I guess the M3 would have all those variants.

  You need to be out of the arduino language to be able to exploit all this things, you can still use the arduino IDE but you need to start playing around with the registers directly. I've done it with the 328 and the mega 2560 without any trouble, just using the definitions as in the manual, with the M3 I'd expect the same but I haven't used it. The transition from the already chewed functions from the arduino language to poking registers can be harsh and do have some traps. When you mess with prescalers and timers you could be messing with the builtin functions as millis() and delay(). Same thing when using ISRs of any kind or the arduino interrupts themselves FWIW. Not to be afraid but to be careful and be aware. For time sensitive application as yours you are better off with lower level than relying on the generic functions anyway.

JS

 

[usekgb]

I am not sure that will be necessary. With 8 bits, giving a PWM 'value' from 256 down to zero, the first 128 values cover a 6dB range. The next 64 cover the next 6dB, the next 32 cover the next 6dB and the next 16 the next 6dB. So a 24dB range is covered by all but 16 'values'. Basically as the attenuation increases the attenuation resolution gets coarser.

Cheers

Ian

Then, if we wanted negative ratios (expansion) we would lose another bit of resolution per step. 

 

[MicDaddy]

sounds like assembly time

Do you guys write in higher-level language with the micro-controllers?  I am limited to assembly

 

[usekgb]

I usually write in C, as I am really not much of a micro guy, but I do use direct interrupts when needed.

 

[JohnRoberts]

It probably depends on the quality of the C routines.

When I started teaching myself programming I bought a C compiler, but ended up reading the assembler code to figure out what the C instructions were actually doing... I ended up never using that C compiler and just writing in assembler.

As an old analog dog, writing in assembler is more literal "do this then if that, do this other this.".

Back on the actual topic, most of the questions have already been answered.  Directly addressed the PWM can be changed faster than appropriate for good sounding dynamics.

JR

 

[usekgb]

So the next step becomes controlling the individual parameters of the compression curve.  Do we want to use presets to emulate different styles of compression, i.e. FET, VCA, opto?  How important is ease of use versus the ability to tweak everything?

 

[ruffrecords]

I have been doing some more research. The frequency of the PWM is is set by the system clock and the value in the PWM prescaler. In the Uno, the maximum frequency is about 64KHz with 8 bits of resolution. The Due has a system clock more than five times faster than the Uno. Its maximum PWM frequency is over 300KHz with 8 bits of resolution.

As for writing code, I would suggest C would probably be best. These microcontrollers are so complex that writing assembler is only an option for small time critical sections of code and I do not think there will be any of those in this aplication.

As for emulating existing compressors, it makes sense to have a separate routine for the side chain to determine the control voltage and another routine for the gain cell  (FET, opto etc) itself. As long as they have well defined interfaces it should be possible to include a variety of alternatives that can be selected at will.

Cheers

Ian

 

[usekgb]

I think shooting for better than 8 bits of resolution would be a good idea, which would eliminate the 328P from consideration.  How many bits of resolution could be obtained on the Due at 200kHz?  Theoretically , a lower clock speed is doable, but it seems like the classic PWM compressors use clock speeds much higher than the Nyquist limit.  Is there something I am missing in the theory that would explain this, or were the engineers just stretching their muscles?

 

[ruffrecords]

I think shooting for better than 8 bits of resolution would be a good idea, which would eliminate the 328P from consideration.  How many bits of resolution could be obtained on the Due at 200kHz?  Theoretically , a lower clock speed is doable, but it seems like the classic PWM compressors use clock speeds much higher than the Nyquist limit.  Is there something I am missing in the theory that would explain this, or were the engineers just stretching their muscles?

Every extra bit halves the PWM frequency so on the Due with an 84MHz clock we can get 328KHz with 8 bits or 164KHz with 9 bits. 10 bits would take us to 82KHz.

When compressors like the Pye were designed there was no digital audio but there were tape recorders and professional types used bias frequencies well in excess of 100KHz so perhaps that was what make then choose 200KHz or so.

Cheers

ian

 

[usekgb]

Every extra bit halves the PWM frequency so on the Due with an 84MHz clock we can get 328KHz with 8 bits or 164KHz with 9 bits. 10 bits would take us to 82KHz.

When compressors like the Pye were designed there was no digital audio but there were tape recorders and professional types used bias frequencies well in excess of 100KHz so perhaps that was what make then choose 200KHz or so.

Cheers

ian

That makes sense.  Even 10 bits would give better resolution at higher gain reduction settings.  10 bits at 82kHz would probably by the limit, as 41kHz is way too close to the Nyquest limit without using complicated high slope filters, and would only provide one more bit of resolution.

 

[ruffrecords]

That makes sense.  Even 10 bits would give better resolution at higher gain reduction settings.  10 bits at 82kHz would probably by the limit, as 41kHz is way too close to the Nyquest limit without using complicated high slope filters, and would only provide one more bit of resolution.

I agree, I would not want to go below 84KHz. I was also wondering whether it made send to use a switched capacitor filter operating at the same frequency after the gain cell.

Cheers

Ian

 

[usekgb]

Switched capacitor would work well, but may not be necessary.  A simple Salen-Key filter should suffice.  I would definitely use a switched capacitor if the frequency were changing.

 

[zamproject]

Hi

Not sure about what I have in mind (maybe just some wrong intuitions), but what about intermodulation between audio and PW frequency?
Maybe that's another reason why analogue PWM comp have a clock at least 10 time the audio frequency.

Also high clock keep relative constant the RMS value and wave form of each audio frequency over the whole spectrum which is switched on/off ?
As theoretical example, a 10kHz audio with a 10kHz PW (50% duty) can have way different wave form at output depending of the sync, from half wave, to symmetrical quarter wave, you absolutely corrupt the wave form.
Same example but 10% duty, RMS value can change a lot depending when you cut the wave, around 0 or at the crest.

Best
Zam

 

[usekgb]

In order for PWM compression to function correctly, the minimum frequency of the PWM would have to be the Nyquest frequency, or twice the frequency of the highest frequency in the program material.  This is very similar to digital sampling.  This should eliminate any issues with frequency dependence and intermodulation.  After the signal is chopped by the PWM, a reconstruction filter is applied to the signal to remove the PWM frequency, leaving only the original signal, at a power level determined by the duty cycle of the PWM square wave.

 

[usekgb]

If you do a Fourier transform of all of the signals, and do the math, the original PWM signal divides out, leaving just the original signal, at a reduced power level.

 

[joaquins]

I vote for C... I don't belive in assembler  Or at least I wouldn't suggest going there unless it's completely necessary.

  For the expander you could just use the range shifted and call zero something other than 100% duty cycle, but as you said it would take part of the scale (exactly 1bit if you use 50% dutyC as reference) An option would be to have 2 independent sections, one for boost and other for attenuation, so you switch 2 sides of the divider. Now, you should be careful with the timing between both depending on what you are doing. You could use 2 resistors and 2 switches and short one or the other but if doing that you should only use one switch at a time, while using 4 resistors and shorting 2 of them gives you 4 usable steps where you could potentially extract better response for the whole range.

  Getting back to the firmware, I guess I'd go for C with nothing fancy to do all the math, doing the processing, curves, shapes, feedback, etc. and interrupts to manage the PWM without the use of libraries, as you may not always know when they are going to bite you. Also be careful to how to drive the PWM output as the µC may have dedicated pins for the timers which could benefit greatly rather than relying on ISR to do the output updating.

  Fast attack times (for brick-wall function) could be done in some clever way, I don't remember about the M3 but the 328 has a comparator which can drive ISR, you could set the comparator to a level (slow well filtered PWM output if needed) and automatically activate the attenuation and then you have like 200 clock cycles to do the math and switch it again when needed. (200 cycles based on 80MHz clock, 100kHz PWM, 2.5dB minimum attenuation for 1 PWM cycle once over the comparator) With this approach you would be responding instantly to the transient, as you have the settling time of your filter to start reacting (from detection in the comparator to action in the ISR, few clock cycles, still faster than the filter) and then the partial PWM cycle to resolve how bad it was.

JS

 

[ruffrecords]

It might be a good idea to think about synchronising some stuff. We are going to need to A/D the audio and update the PWM on a regular basis so there is good argument for doing all of these in one short ISR. If we have say 100KHz PWM frequency that gives us 10uS in the ISR in which to check if A/D results (left and right) are available and store them and restart the A/D and update the PWM registers and increment a tick for timing other operations. Everything else could be done in the background.

Personally I think this is overkill. A lot depends on the speed of the A/D converter and there is no point doing anything faster than the audio sample rate so perhaps a 50KHz ISR would do - a whole luxurious 20uS to play with.

Cheers

Ian

 

[zamproject]

Hi all

What type of filter/integrator can be used to have a good attenuation at 100kHz if the cut off is around 20kHz ?
I mean we need about 100dB to extract all PW noise.

I just do some (online) calculation with 3d order Sallen-Key at Fc=20kHz, it only cut 40dB at 100kHz introducing up to 20uS delay

Best
Zam