A good CS-PRNG can take a modest amount of entropy and store it in a way (internal state) that you trust it can't be recovered by the attacker. From this they can generate a nearly endless supply of random output. That, as I understand it, is /dev/random vs. /dev/urandom/.<p>So it's nice to have a good reliable source of <i>entropy</i>, but you can also consider how protected is the internal state, aka the place you stick that entropy? The better protected the CS-PRNG state, the less entropy you actually need.<p>If you trust the CS-PRNG state, then hardware entropy sources won't matter much to you, because you just don't need that much entropy. When you start streaming entropy from many sources, it's probably to consistently update internal state over time because you don't fully trust that the state is secure.<p>It should make no difference either way in the quality of the output (directly pulling entropy versus CS-PRNG output). Because the necessary amount of output to reverse-engineer state is almost infinite, the output of a properly implemented CS-PRNG is highly trusted. And they're really nice algorithms that have well reviewed implementations.