+1, if your threat model is actually this severe, use physical hardware with physical interlocks and physical security mechanisms.

Software/virtualization is just helpless against such a threat model.

It's an AMD platform, so it's the native AMD HD Audio Controller (17h/19h/1ah), with a Realtek ALC245 codec behind it. I have no idea what other hardware is involved, presumably an external Class-D amplifier IC (but I don't know as there doesn't seem to be a datasheet for the ALC245 available).

Awful, around 3h. It's a nice machine if you need x86 and graphics power.

I'm still keeping my M1 Pro.

> Is there any technical reason it couldn't be generic though? It includes 2 .wav files containing a measured, real-life calibration data for this specific laptop.

If you measure your own device (and it's frequency/impulse response) and replace those .wav files with that -- you're good to go! There's just no universal format/place to put such calibration yet, which is why I published a custom package (incl. the filter config).

I'm kinda hoping more people generate such files for their laptops and share them, maybe we can build a collection of such profiles for many laptops :)

Get familiar with REW and then maybe https://www.youtube.com/watch?v=5YcH7j2-L1Y and you should get pretty close results.

REW can generate a set of peaking/shelf equalizer filters, but why would I want to do that instead of just applying the inverse impulse response instead? It's just more work for a less perfect solution/result...

Exactly correct, that was my thought process while doing it. I tried it without that 300 Hz slope first of course, but that did try to murder my speakers. :)

Same. I really didn't expect that (and thus didn't even test it at first).

lol! The IP stack does not have forwarding support, but I guess you could implement some rudimentary loopback announcement support.

Depends on what you want to do :) If you just want to read/write sectors of 512 bytes at a time, it's pretty easy to implement even on a simple MCU.

There's a couple of registers which need to be set: https://wiki.osdev.org/ATA_PIO_Mode and you can then just read/write the data from the parallel lines.

Here's a similar project using an ATmega32: https://github.com/zwostein/idetrol (i used this code, ported to ARM to check my hardware before I wrote the kerneldriver)

How can this be so easy but talking to an SD card is an impossible task without implementing a billion vendor/type quirks.

ATA was implemented by engineers and then described in a spec.

SD was designed by committee and then implemented as best they could.

Ooh the hours lost trying to reverse the proper call sequence and frequency for my SD card, thanks for the reminder.