On Windows, like other modern operating systems, a driver is supposed to do only the minimum amount of work possible in the interrupt handler, to avoid this problem. The real work is supposed to happen later when it can be scheduled.
While it's true that networking device drivers on Windows defer all meaningful work to post-ISR, it only moves the goal posts a little bit. On Windows, a lot of network traffic processing (e.g. tcp/ip acknowledgment, virtual switch packet forwarding) is performed in a DPC[1] queued in response to the device's interrupt. A DPC generally runs at dispatch level, which gives it more-or-less exclusive access to the CPU until completion. This preempts the thread scheduler and can result in user-visible stutters in audio and video when the network load outpaces the CPU's ability to quickly service the network traffic.
These are hardly complex tasks, they could be done by computers from the 70s. It's quite possible that Windows makes a mess of it anyway, of course.
But the top comment was about how interrupts from the network card interfere with interrupts from the sound card so it can't keep its buffer filled. That shouldn't happen.
Unless the CPU just isn't fast enough to do networking and decode or generate the audio at the same time, but then it's never going to work properly.
