usually, SIMD instructions work by loading the values you want to apply the same operation to into a wide register, and then applying the vectorized instruction to it.
Now, collating values from all over memory to end up in one say 256-bit wide register, just to do 8 multiplications at once, probably doesn't pay.
If you, however, are able to decide the in-memory layout of these parallel streams $x_i$ to be interleaved, i.e.
x_0 & x_1 & x_2 &\cdots&x_7&x_0 & x_1&\cdots &x_7 & x_8&\cdots
then you could load the consecutive values into one SIMD register without need for any memory or register shuffling; that would be desirable.
Again, in your specific case I wouldn't expect too much from optimization for SIMD: If a single-tap IIR is already the bottleneck, your application is not CPU, but memory bandwidth bound.
If you just think you can speed up your application significantly by speeding up this especially cheap operation: I'm afraid that's rather unlikely; if it's trivial to parallelize on an instruction level, your compiler stands a good chance of doing exactly that, and really, one multiply-accumulate per output sample is pretty idyllic, so I doubt there's much to be done, considering the cost of rearranging numbers to make that work (your API defines samples to not be in interleaved order, and your compiler can't do anything about that).
There's other aspects to be looked at; among these are questions like whether
double is really necessary for what is presumably fixed-point numbers with less than 32 bit of dynamic range.