Hacker News Reader

Comment by amluto | Hacker News Reader

I thought Windows had a fancy interrupt priority system that should, in principle, allow sound playback to preempt network interrupts? AMD64 added a fancy feature (CR8 access to the task priority register) just to accelerate interrupt prioritization.

(This is all very vague memory. I know how this stuff works on Linux. Linux does not have interrupt priorities.)

View on HN

I could be wrong, but my understanding of some sound cards is that they have essentially a single memory buffer that they are reading from when instructed to play a sound. Most sound cards let the OS split the buffer into two halves and raise an interrupt when one half of the buffer completes playing.

Interrupt prioritization doesn't help much, because the sound data is likely being generated from user mode, and the playback complete interrupt is being handled in kernel mode, which would require a transition back for further processing. When receiving data from a network card, no transfer back to user mode is required and will have implicit priority over sound generation. Therefore, network processing is likely to starve out sound generation barring choices like those described.

(This is somewhat hearsay, corrections welcome :))

Needing to wake up usermode is not necessarily an insurmountable obstacle; under Linux you can use a PREEMPT config. Storming a network card having unwanted consequences can also be mitigated: under Linux you have some network device driver that use an hybrid interrupt/polling approach with the NAPI. Combining both should theoretically allow a system to generate sound smoothly in the described conditions.

IMO you shouldn't really need to wake user mode that often. Just let user code buffer the output samples well ahead of the hardware needing them and have the kernel do the copies when needed.

Of course if you can do that, it's really good. However, sometimes you need low latency.

Windows does not really have interrupt priorities IIRC. It kind of sort of have some, but the applicative code (device driver included) can't chose at which level they run their ISR, so its quite random whether or not the ISR you prefer should preempt others.

Plus typically general purpose OSes don't map hw interrupt priorities mechanisms to their own priorities (and very soon the hw interrupt controllers do not even know whether an ISR is running or not). I believe neither Linux nor Windows can benefit from hw assistance for interrupt priorities (and they mainly don't care at sw level anyway)

Windows interrupt priorities are called IRQLs, see https://blogs.msdn.microsoft.com/doronh/2010/02/02/what-is-i... for a discussion.

Mostly PnP decides the levels, unless you have multiple IRQs and you need to specify the priority.

That very page makes me think device drivers don't choose their DIRQL. Any more precise pointer to how they can do that?

Reply on news.ycombinator.com