You're right that the M-Audio 2496 has its own DSP on the ICE1712 chip that handles a lot of the audio processing, mixing, and routing independently. The card can do:

Hardware mixing of multiple streams
Sample rate conversion
Digital I/O routing
Some effects processing

So for basic audio I/O, recording, and playback, the host FPU speed shouldn't matter much - the card is doing the heavy lifting with its onboard DSP and DMA transfers.
However, FPU performance would still matter for:

Plugin processing - VST/AU effects and instruments running on the CPU
Soft synths - All computed on the host
Real-time effects chains - Reverbs, compressors, EQs running in the DAW
Mixing/bouncing - When the DAW is doing CPU-side processing

The 2496's DSP handles the interface between digital/analog and manages the audio streams, but all the creative processing (plugins, virtual instruments, etc.) still happens on the host CPU's FPU.
Given that your emulated FPU performance is weaker than native G5 (as you mentioned with your Geekbench results), you might hit limitations with heavy plugin chains or complex soft synths, even though basic tracking and playback through the 2496 should be fine.
The real test will be loading up a session with multiple plugin instances and seeing where the bottleneck appears. The 2496's DSP helps, but it can't compensate for CPU-intensive creative tools.Claude is AI and can make mistakes. Please double-check responses.

Hey redstudio, I cropped and downsized your images for easier viewing (hopefully without the need for scrolling). 

And... where did you source the new speakers? [For those that might also wish to replace theirs in a similar way.]

*I've three 17" G4 PowerBooks... and lucky I suppose, all have not yet succumbed to such rot.

Good catch! You can find burnt-out voice coils by measuring the terminals with an ohmeter. A 4-ohm driver will be around 3.5 ohms at DC normally, but "+OL" if it burnt out.
The rubber diaphragm may have been chosen for a lower resonant frequency vs a plastic cone, but we now can see how they degraded with time.

new

broken speaker

I think I've solved the mystery of the PowerBooks with no sound; it's the faulty speakers. Of three laptops I've opened, they're the ones that don't work (tested), and the reason lies in their construction. Normal speakers use a paper or plastic cone with a rubber surround, which usually wears out or decomposes over time. These speakers have a rubber cone and surround! Of the three I've inspected, two had cracked rubber that prevented the cone from moving. One moved, but the rubber was flaking, and the voice coil got stuck. I think the problem with the voice coil has burned them out over time. If they were installed in all aluminum PowerBooks, they're definitely not going to work anymore. what a strange choice to use rubber for the construction of everything which is the only element that deteriorates in classic speakers.. however ordered in plastic (found similar product of dimensions.. 2 cm original 4 ohm 6w unobtainable, taken 8 ohm 1w they will sound half, but for test..) tried to replace them in a test powerbook.. it was exciting to finally hear the initial "boing"!

Welcome to Mac OS 9 Lives, jjuran! MacRelix is awesome! Glad to have you here

Sorry, I need to temporarily take down the downloads page on the main site. We're moving the website and the downloads to a new host. The downloads are up on the Hotline server though, so grab them from there (like aBc mentions).

My idea is centered around getting apps to work by providing an environment that is identical to the Macintosh Toolbox.

[discussion of the challenges of improving Mac OS 9 snipped]

This is why I went down a path of sandboxing on Linux. Linux is open source, it has a substantial amount of hardware support... You can install Linux on PowerPC hardware.

I thought it might be plausible that a sandbox could reimplement the Macintosh Toolbox to target system components in Linux (X Window, PulseAudio, networking, etc). I understand there would be an overhead because Macintosh Toolbox would require thunking/translating API calls to Linux and back again - however given hardware has improved over the journey the speed might outweigh the overhead.

The gain would be to run MacOS 9 classic apps on many facets of hardware, having graphic/audio/input/network support across the board.

Rethinking this strategy, the biggest hang up I have is how Extensions/Control Panels hook into MacOS, how that might affect the ability to change the behavior of a sandboxed MacOS at runtime.

Food for thought.

Hi, I'm the developer of Advanced Mac Substitute, which you referenced earlier.  I have a perspective that both intersects and diverges from yours.

Advanced Mac Substitute
https://www.v68k.org/ams/

Reimplementing the Mac OS and Toolbox is a sound idea — I'm hardly the first to do so.  But bear in mind what an enormous task it is.  The road to Carbon reimagined how windows, controls, and menus work, adding many new API calls (to say nothing of Carbon itself).  QuickTime alone has hundreds.

This is why I chose to start at the beginning and move forward chronologically, more or less — it's the shallow end of the pool.  (In practice, my current target is System 6 and I focus more on what features are needed vs. which version introduced them — which explains why I have Gestalt() (added in System 6.0.4) but no Disk Driver (since System 1).)

That implies focusing exclusively on 68K for now.  That, in turn, calls for emulation.

Which is just as well — virtualization involves more complexity in general, and in Mac-on-Linux's case, requires the host OS trusting the guest with privileged access (removed in Linux 2.6).  Whereas emulation is essentially just number crunching with a large array.

Every reduction in complexity or scope helps make the overall problem more tractable.

(Performance just isn't an issue, even on a 15-year-old x86_64 processor.)

I've taken a factored approach:  The 680x0 interpreter core and the reimplemented Mac OS form the back end of the system, while an an application that displays graphics and relays user input is the front end.  A front end is a much smaller body of code to manage than the back end.  I've written five implementations just for macOS alone.  Linux is supported via fbdev, X11, and most recently (thanks to a colleague), SDL2.

In addition to the front and back ends, there are one or more file servers and a optionally a sound server active.  The sound server is itself split into a library that implements the individual synth modes of the Sound Driver, and an API driver, either PortAudio or Sound Manager (for really old Mac OS X versions).  PortAudio works just fine on Linux; I have no intention of targeting PulseAudio directly.

(I don't have a way to run cdevs yet, but any 'INIT' resources placed in the System file will load and execute.  On a Mac, files of type 'INIT' in the bootstrap file area will also be opened and checked for 'INIT' resources.)

There's another drawback of continuing to use Mac OS 9, whether in emulation or on real hardware:  Many applications just don't work in it.  (I was going to use Déjà Vu as the initial demonstration of Legacynth's capability, but (a) if you forget to start Legacynth, it hangs trying to play sound, and (b) even with Legacynth running, the sound works fine but the application eventually crashes.  I ended up writing my own demo app.)  With emulation, you can run applications in different environments on the same host, simultaneously.

In summary, I agree that sandboxing is vital for the future.  (Though I'm also in favor of small system or application patches that improve quality of life for existing users.)  However, preservation of our culture and the ability to share it with younger generations is too important to limit it to one operating system or CPU architecture — especially one without the speed and economy of scale of modern microprocessors.

I hope this was useful. :-)

Very interesting history! Thanks for sharing. I also read the article on the history of MacRelix you shared. It's not everyone that would continue a project like that long after Mac OS X came out. But it sounds like you are a truly passionate developer. Both pursuing whatever catches your next interest and also seeing things through to the end.