In this case it would look the same in assembly as C. As you are in user mode using file mapped I/O, all you would be doing in assembly is pushing parameters and performing writefile/readfile syscalls to the kernel. You can't access the hardware directly in user mode in a protected multitasking kernel. There is almost no point to writing user mode apps in assembly because all you're doing is calling kernel syscalls to do anything.
How is the kernel doing it? A driver and careful arbitration between multiple streams and a kernel sound mixer and so on.
What is the driver doing?
Probably reading/writing to the sound card registers at 22xh or whatever the hell they use now (look up old school DOS SoundBlaster digital audio programming, it's actually very simple), or rather programming DMA to dump your data that you've written to a buffer in user land 2 bytes at a time, 44,100 times per second or whatever your sample rate is or likewise reading data from whatever register is sampling 1 sample of data on the mic, also at 22,050 or 44,100 times per second to your file buffer so you can fread it. Do modern sound devices like the common onboard Realtek chip still use the classic SoundBlaster I/O space? Is legacy SoundBlaster compatibility still even a thing? I have no idea!
If I recall with the old SoundBlaster DOS programming the DAC isn't directly exposed to the host CPU, or at least not used, but rather there is at least like a 16 byte or more read/write FIFO per stereo channel on the sound board so that you can use DMA to read/write data faster than the sample rate so you have some bit of asynchronous operation for at least a few samples before you have to read/write again. Otherwise you have to have your CPU sit there and babysit the DAC or risk missing samples.
For what you want to do, DOS is still your best bet for learning. Or an old game console like the Gameboy Advance where all this stuff is WELL documented and accessible to your program with no OS or other processes to worry about. It's far easier to learn hardware tinkering without the complexities of modern OSes in the way or doing kernel/driver development.
I recommend get yourself a GameBoy Advance with a Flash cart, the Virtual Boy Advance emulator which has real time memory viewing and an assembly debugger with single stepping, and the GBA ARM7 GCC. You're also working from a ROM cartridge so you get to deal with the concepts of powering on in ROM and having to copy stuff to RAM, initialize the hardware to a known state, etc when you start up. And ARM7 is a dreamy instruction set and the GBA is crude enough to get the basics but with a nice clean flat linear 32 bit memory map with no segmenting bullshit and no cache or complex memory management to deal with. You get some VRAM with some hardware defined display modes (several tile and bitmapped modes), an audio DAC, a couple DMA channels, like a 3 instruction prefetch buffer, some RAM, sprites, etc.
In fact your first program is going to be a hello world that just sets the screen to a solid color via the palette to verify that you are compiling, linking, and executing correctly. Before that you can write a single instruction, then load your ROM in the emulator and look at the debugger and see if you see your instruction is there at the correct startup address. If you want text, you have to create your own character set tiles and make your own string functions write the tiles to VRAM and everything. It's new enough to be simple and easy without any technology limitations or backward compatibility with the 70s encumbering and complicating the architecture, but old enough that it's simple and not overwhelming like a modern computer.
And there is a DAC with 2 DMA channels dedicated for stereo that you can play with in assembly
And some timer channels. Numerous examples and home brew support for writing a music tracker and mixer and all that.
Facebook
Twitter