The Inquirer-Home

Generic PC audio turns intelligent

Analysis Intel DSP follows Creative path
Mon Sep 01 2008, 12:01

ONE PARTICULAR talk during Intel's International Developer Forum was innocently named "Audio Architecture for Mobile PC Power Consumption Reduction" - sounds boring, doesn't it? Well, under the guise of this long title hid the unveiling of a major shift for generic PC audio after many years, finally.

Since the Pentium III days - or at the time when even Windoze OS was far less of a resource hog than it is today - Intel was at pains trying to create justifications for us typical users to fork out cash for high-end CPUs when there wasn't much need for them.

One method was to promote 'soft power': not the approach that the good ol' US-of-A sorely misses these days in trying to make new friends globally, but loading all (even the most mundane) I/O tasks onto the CPU. So, the reliable old-school serial and parallel ports โ€“ anyone still remembers RS-232/422 and Centronics โ€“ were to be replaced by CPU-hogging USB where every peripheral polls the CPU every millisecond or so, even when absolutely inactive.

Software RAID for storage became yet another CPU load-bearing addition, and so did software "modems", not to mention the later occurrences of fully software-based Ethernet and wireless LAN stacks. Did I also mention "integrated graphics"?

Finally, we witnessed the arrival of software sound: the audio codecs, instead of hardware, became software stacks. Now, this was literally 'icing on the cake', and not just for Intel. We still recall our benchmarks on early AMD Athlons, where the AMD software audio chipset, compared to Nvidia Nforce's Sound Storm hardware DSP-enabled high-quality audio, was losing in-game benchmarks even with two CPU speed grades advantage!

And that was just bog standard stereo, none of your 5.1 surround and digital doodads.

So, if stuck with a "software everything" I/O on your platform, and in need of consistent performance, you had little choice but to hop up those few CPU grades - at often double the processor chip price. Oh boy, how much more advanced were home computers 20 plus years ago: Commodore Amiga had everything better, from Moto 68000 with its far more advanced ISA than X86, to dedicated graphics and sound processing, not to mention more advanced multitasking than Windoze up to WinNT. All that in 1986 for a couple of hundred quid...

Anyway, fast forward to 2008. CPUs today themselves are power hogs, with 130W TDP even without any overclocking - that whole Amiga didn't consume that much. Even these multicore monsters, with RAM amounts akin to Cray 3 - generation supercomputers sometimes, get bogged down by even increasing Windows OS footprints. The current Vista generation is an example unto itself, taking 2 GB RAM and untold threads just after the boot, without really running anything yet!

Add to this all the 'software I/O' interrupting the CPU non stop (pun intended). Maybe, from the performance point of view, Intel and AMD still wouldn't mind the sales gain from pushing the higher CPU speed bins. But the 'green computing' and 'energy saving concerns' kicked in. Instead of consuming a 20 per cent chunk of a 130 W CPU, all that sound stuff could be done even better and faster by a less than half watt audio DSP! With the current integration levels, it can simply be embedded in the current footprint of that 'software assisted' audio codec chip on most mainstream mobos.

Any excessive power usage problem hits the notebooks first, of course. An Intel presentation stated that a combination of Vista and new hi-fi audio formats increases audio power consumption by as much as 500 per cent. It even grabs an extra 4 W during movie playback and can go even higher. This is large enough delta to impact the battery life - up to extra 30 minutes according to Intel.

That huge saving could be realised not just because of the nominal watts difference, but also because the real-time nature of software audio, with its millisecond-frequent interrupts which prevent the CPU from dozing off into the lower power states, even if there's nothing else to do. The HD Audio Link 20 microsecond DMA prevents entering the lower power chipset and memory states, too.

Where's the crux of the problem? The decode stage on a mobile CPU takes up to 2 W of power, with sporadic but high CPU utilisation. The post processing stage keeps the CPU utilisation high, but more continuously - again around 2+ W of power. Then add the HD Link and its memory traffic with another above 1 watts, and you're getting the picture.

This can, of course, get even worse. Intel says that the power requirement for a 120 dB signal to noise ratio, a figure close to top Creative / Auzentech and Asus cards' capability, can increase computation by up to eight times compared to the 100 dB one. And that's without counting the effects, speaker virtualisation, and such.

Dolby True HD alone can eat 20 per cent of a mobile Penryn CPU capacity by itself, then add some other audio processing stuff. You think telephony is easier on the CPU? No - just the mic noise reduction, various VOIP encodes and decodes and such regularly exceed 5 to 6 W of extra CPU power load on a notebook.

Intel's solution? Off host processing, offloading the burden to Audio DSP and bypassing the OS real time to kill off the interrupt load. At the same time, instead of a zillion small data transfers, they are consolidated into far fewer longer DMA bursts, that not only improve performance and save power, but are also better suited to burst-optimised DDR3 memory, for instance. Related to that, the media player software would then hold larger chunks of that audio content in memory, rather than exchanging smaller segments from the Net or storage.

The overall architecture proposed is based on a ~300 MHz DSP with up to half a gigabyte of dedicated memory and all the hardware accelerated stuff - take a look here:

alt='audiocodec'

The other direction is integration within the chipset or current mainboard audio footprint. This would focus on just four key areas: media codec and transcode; transducer optimisation for voice and noise processing; voice recognition itself, and gaming and 3-D positional audio. Good enough relieve off a big chunk of power-sapping headaches.

alt='audiointegr'
Intel also demoed a FPGA-based early design of what we could have in the follow-up chipsets, too - take a look at the combination:

alt='audiofpga'

Finally, Realtek's upcoming ALC 269 'Vienna', the Audio DSP fitting into the 64-pin layout of the existing software-assisted mobo audio chips, was also discussed. This might be the entry point for hardware audio next year.

alt='audiorealtek'
The benefits? Tremendous - less power usage, higher overall system performance, more powerful media players. Oh yes, now you could give the PC a voice command when it is in S3 sleep state for instance, when the OS is unavailable otherwise.

What about Creative? Besides the high sound quality, its main sales premise is a high-powered, DSP-based audio effects processor. Of course, its 10 BIPS engine can do far more than a miniature Realtek DSP, including beyond Hi-Fi - yeah, X-Fi - HD audio, unreal sound effects and zillions of voices in hardware, all without loading your CPU. Creative will, I believe, keep its niche here. In fact its job will be made easier now that, with Intel's push, Microsoft will be forced to support audio DSP offload in its next Vista and beyond update.

Asus Xonar cards may benefit a bit too, as the missing 'basic DSP' piece there can now be provided by Realtek to work with Asus' effects engine. Nevertheless, I still think the merger of Creative and Asus audio card lines makes perfect sense as the EAX standard would then gain critical mass to become... well, a standard.

Ultimately, we could (and should) do the same for RAID, Ethernet and Wireless stacks. Even the promise of USB 3.0 spec to stop that irritating CPU polling is also important.

So once again we look forward to the glorious past of home computers and hardware-accelerated I/O of all kinds. ยต

 

Share this:

blog comments powered by Disqus
Advertisement
Subscribe to INQ newsletters

Sign up for INQbot โ€“ a weekly roundup of the best from the INQ

Advertisement
INQ Poll

Heartbleed bug discovered in OpenSSL

Have you reacted to Heartbleed?