[JanWillem32]

The new schedulers indeed won't drop frames (these will only try to modulate ready frames if it's really late or early), unless desynchronization by the global timer is detected (which allows huge time differences of the audio and video timers). In that case, timers for both the video and audio renderer are reset. The old scheduler will still often drop ready frames from the mixer, or prevent frames from decoding, with any sort of interruption in my case.

The "#define PI acos(-1)" just converts to a constant floating-point number. You can take a look at what a pixel shader stores in its registers by opening the "Shader editor", make the compiler compile some code, extend the gray bottom box to readable size, and scroll trough to the output assembly. (A somewhat faster alternative for developers is to compile a .TXT file, using the fxc.exe utility in the DirectX SDK.)

// Parameters:
//
//   float c0;
//   float c1;
//   sampler2D s0;
//
//
// Registers:
//
//   Name         Reg   Size
//   ------------ ----- ----
//   c0           c0       1
//   c1           c1       1
//   s0           s0       1
//

    ps_3_0
    def c2, 0.375, 0.3125, 0.5, 2
    def c3, 1, 1.57079637, 6.28318548, -3.14159274
    def c4, 4.93480206, 1, 2, 0
    dcl_texcoord v0.xy  // tex<0,1>
    dcl_2d s0

#line 27
    mad r0.x, v0.x, c2.x, c2.y
    mul r0.y, r0.x, c0.x  // ::coord<0>
    frc r0.y, r0.y  // ::t<0>

#line 34
    add r0.z, r0.y, c3.x
    mad r0.w, r0.z, c2.z, c2.z
    frc r0.w, r0.w
    mad r0.w, r0.w, c3.z, c3.w
    sincos r1.y, r0.w
    mul r0.w, r0.z, c3.y
    mul r0.z, r0.z, r0.z
    mul r0.z, r0.z, c4.x
    rcp r0.z, r0.z
    sincos r2.y, r0.w
    mul r0.w, r1.y, r2.y
    mul r0.z, r0.z, r0.w  // ::Lanczos2wQ0<0>
    mul r1.xy, r0.y, c3_abs.wyzw
    sincos r2.y, r1.x
    sincos r3.y, r1.y
    mul r0.w, r2.y, r3.y
    mul r1.x, r0.y, r0.y
    mul r1.x, r1.x, c4.x
    rcp r1.x, r1.x
    mul r0.w, r0.w, r1.x  // ::Lanczos2wQ1<0>

#line 29
    mad r0.x, r0.x, c0.x, -r0.y
    add r0.x, r0.x, c2.z
    mul r1.x, r0.x, c1.x  // ::coord<0>

#line 33
    mov r1.yw, v0.y
    texld r2, r1, s0  // ::Q1<0,1,2,3>
    mov r3.w, c2.w
    mad r3.z, c1.x, r3.w, r1.x

#line 38
    mul r4, r0.w, r2

#line 33
    mad r1.z, r0.x, c1.x, -c1.x
    mad r3.x, r0.x, c1.x, c1.x
    texld r1, r1.zwzw, s0  // ::Q0<0,1,2,3>

#line 38
    mad r1, r0.z, r1, r4
    add r0.xz, -r0.y, c4.yyzw
    mul r4.xyz, r0.xxzw, c3_abs.wyyw
    sincos r5.y, r4.x
    sincos r6.y, r4.y
    sincos r7.y, r4.z
    mul r0.w, r5.y, r6.y
    mul r4.xy, r0.xzzw, r0.xzzw
    mad r0.x, r0.z, c2.z, c2.z
    frc r0.x, r0.x
    mad r0.x, r0.x, c3.z, c3.w
    sincos r5.y, r0.x
    mul r0.x, r7.y, r5.y
    mul r4.xy, r4, c4.x
    rcp r0.z, r4.x
    rcp r4.x, r4.y
    mul r0.x, r0.x, r4.x  // ::Lanczos2wQ3<0>
    mul r0.z, r0.z, r0.w  // ::Lanczos2wQ2<0>

#line 33
    mov r3.yw, v0.y
    texld r4, r3, s0  // ::Q2<0,1,2,3>
    texld r3, r3.zwzw, s0  // ::Q3<0,1,2,3>

#line 38
    mad r1, r0.z, r4, r1
    mad r1, r0.x, r3, r1  // ::main<0,1,2,3>
    cmp oC0, -r0.y, r2, r1  // ::main<0,1,2,3>

// approximately 114 instruction slots used (4 texture, 110 arithmetic)

Not too bad, as far as I can see. (Reading assembly isn't easy. Also note the the nasty habit of the compiler to truncate numbers to less decimal places than it usually stores in its binary format.)