Audio Weaver Worksheets: What They Actually Are
Au and Aw worksheets live inside Analog Devices' Audio Weaver Designer, a visual DSP development environment. The "Aw" part refers to Audio Weaver itself. You build signal processing chains by connecting modular components on a grid, then export those worksheets as compiled code for SHARC or Blackfin processors. There's no magic here. It's a way to visually wire together filters, delays, mixers, and effects before the code ever touches hardware. I spent weeks trying to get a multiband compressor to behave on a Blackfin project, and the breakthrough came when I stopped fighting the worksheet layout and actually respected how the compile chain resolves dependencies. Audio Weaver walks your modules top-to-bottom, left-to-right, and if you cross wires in a confusing pattern, the compiler silently produces a wrong timing relationship. I found this out after my compressor had a 3ms delay relative to the dry signal, and it took me three days to trace it back to a stray bus route that crossed under a delay block. The workflow goes like this. You open Audio Weaver Designer, start a new project, and drop modules from the library onto the canvas. Each module represents a block of DSP: an IIR filter, a gain stage, an FIR, a dither engine. You connect them with wires. Once the chain looks right, you set up the build targets in the project settings, choose your processor family, and hit compile. Audio Weaver generates C source files that you drop into your embedded project.
Some things that aren't obvious from the documentation. The worksheet grid is not just cosmetic. The placement affects optimization. Modules placed earlier in the read order get scheduled first, which matters when you're working with tight cycle budgets on older SHARC cores. The compiler doesn't reorder things arbitrarily for you unless you tell it to. If you need automatic optimization, you have to explicitly enable the scheduler in the project configuration, and even then, it sometimes places a high-priority multiplier chain second because it couldn't resolve a data dependency without breaking your topology. I learned to manually arrange critical signal paths in dependency order rather than relying on auto-layout. It saves about forty minutes of debugging per project. Another thing beginners miss. The parameter tables in Audio Weaver are not static. You can hot-patch coefficients at runtime through the control interface, but if you change a filter cutoff frequency while audio is flowing, you'll get a pop unless you ramp the parameter. There's a built-in ramp function you can attach to any parameter, but it's not enabled by default. I've seen engineers ship worksheets with abrupt coefficient changes in production firmware because they assumed the framework handled it automatically. It doesn't. You have to wire the ramp module yourself. Here's a practical example that covers the basic path. Let's say you need a simple two-band equalizer with a crossover at 2kHz. You drop a Linkwitz-Riley crossover module, route the input to both branches, add a parametric EQ to each band, sum them back together, and send to output. In the worksheet, that's maybe six modules and eight connections. The compile produces roughly two hundred lines of generated C code plus your hand-written main.c file. On a SHARC 21489, this processes stereo audio at 48kHz with about 800 cycles per frame remaining free. That sounds fine until you realize you also need a delay compensation path, and suddenly you're at 95 percent utilization and there's no headroom for anything else.
Performance limits are the real bottleneck with these worksheets. The graphical interface makes it easy to overcomplicate a chain because adding a module takes one click. Before you know it, your project has sixteen modules when eight would do the job. I started measuring cycle budget early in the design phase instead of at the end. There's a cycle analysis tool in Audio Weaver under the Project menu. Run it after every major topology change. If you're burning more cycles than your processor can spare at your target sample rate, you need to simplify or move to a faster core. Simple as that. One more thing worth noting about the module library. It's not exhaustive. If you need something that isn't there, you have to build a custom module using C, compile it as a shared object, and register it with the designer. This is documented, but the documentation is sparse on edge cases. I spent a day figuring out that my custom module's coefficient update callback wasn't firing because I'd forgotten to declare the parameter as volatile in the registration struct. The worksheet looked correct. The behavior was wrong. The cycle counter showed the module was executing. Nothing in the logs pointed at the actual problem. If you're evaluating whether to use Audio Weaver for a project, be aware that the licensing model is expensive for small teams. A single designer license runs into thousands of dollars, and additional target licenses multiply quickly if you're developing for multiple processor families. The free evaluation version works fine for learning and prototyping, but you cannot legally use it in shipped product. If budget is a constraint, consider building your DSP chains directly in C or using a lower-cost toolchain, though you lose the visual workflow and the automatic code generation. There's no middle ground in the analog device ecosystem that I'm aware of.
Get the Full Details
