Not wishing to troll, but... Really? I recently had to implement a similar thing for a public transport voice announcement system (certain parts of the world require ambient noise compensation on their passenger announcements (plus sometimes customers want that anyway)).
As you say, running average (or similar) of RMS is a key part of it... but other than some very (very) simple logic and arithmetic (basically scale the volume (up to a limit) based on a scaling of the RMS against a calibrated value), nothing more was needed.
Was it particularly more complex when implementing this for use in a room (as opposed to on a vehicle)? I guess the more dynamic nature of TV/film vs. passenger announcements would probably make it a bit trickier.
Just curious :-)

(Oh and I agree on your last statement. The problem has only existed 'cos advertisers know they can get away with it, nothing technical at all!)

aaaand Thesaurus boy!

I'd hope he only wore it at home (if at all).

Its a safe bet that this chip has DMA capabilities for most, if not all of its built in peripherals. Otherwise you're left to perform interrupt or polling based data transfers which just wouldn't let it get anything done.
I don't know this for a fact, but I'd say that all chips in this class have DMA capabilities. A few ARM chips now seem to have quite flexible DMA that allows for BitBlt operations which can be quite handy.

What about that whooshing sound... how much do you care about that?

Or maybe the cat didn't have a collar because the owner was worried about the risk of strangulation, which can happen even with elasticated collars. I don't think you can say that the owner didn't care about their cat because of the lack of collar.

I know this. My point is that in some cases the source is enough, because you can use knowledge of other visible aspects of the system (such as the bootloader) to create your own build environment.
Somewhere else in the comments people were complaining about the fact that although you can unpack some source and build it, the method needed to create the binary image suitable for flashing on to the device is a complete unknown if you don't have build scripts. I don't think this is necessarily the case if you're prepared to put it the work and have the relevant knowledge.

Anyway, as you said, its all about patching the binary if you're gonna do it properly!

Actually... I've seen a few commercial ARM compilers that are supplied with microkernels (Keil is one that springs to mind). And the Linux distribution I'm currently using from Texas Instruments for one of their ARM chips is supplied with a gcc cross-compiler compiled for Linux and Windows (and I think even OSX).

As much as not having the build environment (ie. scripts) can be an annoyance, companies seem to often use uBoot or RedBoot [yes, citation needed, I know... this is just what I've seen so I could be very wrong], meaning that if you have an upgrade image to pick apart, you can work out how you're meant to be building your own upgrade image.

So, err, how did you come across that picture then?

Strange how a British website is selling stuff in dollars

Ooh and with that unification think of the DRM possibilities!

'splain me how ARM can be 'the embedded processor maker' at the same time as not making any processors, please.

Not to be a pedant or anything (spare the thought!) but ARM don't actually make any processors. They own and control the core IP that is licensed by various processor and SoC manufacturers.

However, ARM processors do seem to be the most popular processors for embedded systems. Which I think is what you meant.

Fnarr fnarr!

Maybe you have to make a big show of pretending to throw stuff away. Maybe in front of some other, more modern hardware. That'll trick 'em!