You're supposed to seed your PRNG only once at the beginning of your program, so only if you actually start your program every 10 or 100 nanoseconds is the current time going to be insufficient, but if you do that, I think you've got worse problems to solve anyway.
edit: For encryption, you need to add more entropy to the system during the execution, but you can't use a seed that's easily guessed, (such as time), so the situation is much more complex anyway.
Also, with most PRNGs seeding the PRNG from it's own output will actually decrease entropy, so doing it is
bad idea. The only common PRNG where this is not an issue is the classic linear congruent generator, when it's implement such that it returns the full state (that is, 32-bit state for a 32-bit return value), in which case seeding the last random number is basicly no-op (since the last value would have been used as a new seed anyway).
I'll leave it as an excersize to the reader to prove that it's impossible to design a PRNG for which srand(rand()) actually increases entropy.
Anyway, with random numbers it's important to ask yourself first: how random you need the values to be. For something like audio noise, the quality is more or less irrelevant (linear congruent is fine, speed is much more important). For stuff like simulation, you need high quality series on numbers, but it's actually a good thing if you can use the same seed several times (allowing you to repeat the same experiment).
For cryptography, you'd better forget about writing your own generator, as you not only need a high quality series, you also need to collect entropy from some unpredictable (external) source, and you must avoid leaking information about the generators internal state.