If you're not scared of some heavy nerding, you can also just get the bytes from the wav files via the Data nodes and convert the sample range from the file to the Y-values you need. That way you get straight to the data you want instead of going through a build/process list step.
Be aware of the endianness of the wav data (Stackoverflow look at the second answer/The Canonical WAVE file format). Although the data starts at byte offset 45, it's little-endian meaning that you want to start at byte offset 46, and skip every other byte as you won't need the details for a display anyways. You can probably skip even more bytes in total, just add 2 to the skip count to decrease the resolution..
I'm too slow to figure out the formula, but you also probably want to shift all values above 127 to be in the negative range. Since the byte values are naturally unsigned they are subtracted from the maximum byte value (255).
Oh, and you have an offset from the input in your lines. Your list starts at the beginning of the line, but the control signal doesn't come in until where the linear behaviour ends. This is probably why the waves are out of sync as well. Try cutting the input list going to the line object node from the beginning until it syncs up/starts at the wave.
Does it have to be line objects if you only want to display pre-existing wav files? You can do something like the example display by using the waveform images and output it to 3D-squares and arrange those to your liking.
This is one stream split by frequencies, but it should be easily adoptable to multiple files as well. Requires playback to display, but I would guess that's the point?
From the limited data set Apple provided, a somewhat educated guess would place it somewhere around a gtx 1060 (Apple's comparisons was seemingly in regards to the Intel Iris Plus 645). This also aligns with the recommended graphics card for Baldurs Gate 3. This is speculation, but I'll be surprised if I'm very far off (we'll see how well this comment ages in a couple weeks ;) )
The part about accelerating their software is absolutely correct, but that is also the problem. Apple specific software and software using the same hw features (without competing with Apple software) will benefit. As Apple doesn't focus on graphics intensive applications, they have no incentive to improve in this area (which also should be pretty obvious looking back at the last 10 years). I fully expect them to add a "FX engine core" or some other marketing-aligned sales pitch if post fx becomes a focus area though. That won't help generative stuff.
I think going forward Apple will be for convenience and battery, power will be had with Windows/Linux (which both have been on ARM for some time now as well).