That's what Audio HLE is for (more or less), but what it does is rather interesting. HLE stands for High Level Emulation (I think). To compare, assembly is a low level language. It's very specific, and will only run on the CPU it's written for. C++ on the other hand is a high level programing language, and can easily be compiled to run on multiple systems. So, for HLE, rather than emulate the hardware of the N64, it only emulates it enough to run the most common commands. It's a very loose interpretation of the hardware, more or less. As such, because it's less complex, it takes less CPU. In fact, that's what made N64 emulation possible (with the first emulators, they couldn't emulate the hardware of the unit, so the did HLE, which covered most games, but left a few, smaller, details out). Obviously, since then, emulators have been improving. From what I gather, most homebrewn N64 software doens't run on emulators very well, because most emulators are based on HLE usage. As the emulators improve, their compatibility increases, as do the commands that can be run. Eventually, if given enough time, the emulators won't need HLE at all (and in fact they're generally MUCH improved from what they used to be. HLE isn't used much anymore, from my understanding) and will run all the games they come across, including homebrewn stuff. However, that is a VERY VERY long way off, based on the amount of updates N64 emulators see...
Anyway, now you know some of the background of HLE, and why it can be useful, and how it was used. Probably a little more than you cared for though. Nonetheless, enjoy, and hopefully this helps enlighten some people in the area of emulation, a little. Mouser X over and out.
To clarify a bit: HLE in the N64 emulation sense means emulating the behavior of software rather than emulating the beahvior of hardware running that software. This generally takes 3 forms with the N64: audio, video and CPU emulation.
CPU: A huge number of games (if not all) use the N64 operating system, referred to as libultra. This provides threading, message passing, and all sorts of things to make development easier. The thing is that since the N64's BIOS is only a few kilobytes in size, it's only purpose is some security features and loading a bit of code from the cartridge. The OS is actually stored within the game itself. What high level CPU emulators (such as that in UltraHLE) do is locate a lot of standard OS functions and replicate their behavior without having to emulate them one instruction at a time. Often this works very well.
audio: The N64 contains a second processor called the RSP, which is often used as a programmable DSP (Digital Signal Processor), that is it's function is to perform a limited (but customizable) number of operations on large amounts of data. To this end the RSP runs a bunch of different programs called microcode (often abbreviated ucode, where the u looks like the Greek mu, often used for micro) which themselves run lists of commands sent from the main CPU called Audio or Display Lists. In the case of Audio Lists the RSP is running audio ucode, which performs the synthesis work involved in combining instrument samples and sound effects into a continuous stream of uncompressed data which is played directly by the Audio Interface. There are a few different kinds of Audio ucode, and some brave souls have endeavored to explore their intricacies and figure out how they do their work, then write code to duplicate the behavior. It is much less CPU-intensive to do audio synthesis than to emulate hardware doing audio synthesis. Azimer's HLE, which was once based on Ultra HLE's own audio but has come a long way since then, is one such plugin.
video: N64 video HLE is pretty similar to audio HLE. There are video ucodes that run on the RSP, they take Display Lists of "high level" descriptions of scenes and perform various matrix transformations, cut out bits that won't be seen, and put everything in a state ready for processing by the RDP (Reality Display Processor), which has a fairly simple set of commands for drawing textured triangles and rectangles. Video HLE takes the Display List and attempts to interpret it the same way the video ucode would, but it generates commands not for the RDP but rather Direct3D commands that run directly on the host OS (via your computer's video hardware). Thus the idea is to save processing power both emulating the ucode and emulating the RDP's rendering procedure. Most emulators today will use this by default beacuase it's fast and works pretty well, but there are still a lot of games that don't look right with default settings.
---
and to clarify I bit more, I'm using a friend's computer in California, so I'm not back yet (and won't be 'till tomorrow).