For randomness extraction, in some cases, you could use alternatives to hash functions. However, mostly hash (or hmac) is preferable, because hash and hmac are very good in extracting randomness.
RFC 5869 describes HKDF, HMAC-based extract-and-expand key derivation function, with randomness extraction and expansion phase.
NIST has made equivalent standard from HKDF, NIST SP 800-56C, which also allows AES-CMAC as alternative to HMAC. Thus, NIST SP 800-56C compliant randomness extraction can be done without hash functions by using AES-CMAC instead.
However, NIST SP 800-56C is only usable when there is a good reason to expect that input contains sufficient entropy to meet the intended entropy of the output.
Another obvious approach is that you could create NIST SP 800-90A Deterministic Random Bit Generator using AES-CTR algorithm with derivation function. The randomness you want to extract could be input entropy to the algorithm.
Estimate entropy
However, for both of uses described above, you need good means to estimate how much entropy you have within the input. If you use something like NIST SP 800-56C and you did not have enough entropy in input, you don't have lot of entropy in output either. For this reason, it is critical you can correctly estimate how much entropy you have.
Usual compression functions, for example, like CodesInChaos mentioned above are not good enough, for determining the amount of entropy. They can give pointers. Just never expect a compression function to produce full entropy.
Linux kernel's /dev/random uses various mathematical means to estimate amount of entropy present in the events in information theoretic sense. This is in fact something pretty close to compression. However, it does not actually compress anything, but instead selects entropy estimate which is strictly smaller than any compression approach it could have used. A lot of information about Linux /dev/random is in this analysis. The analysis is old, and the issues found are largely fixed, but the basic structure remains the same.
For estimating the amount of entropy, it is necessary to understand what kind of input materials you have. Software like ent are useful to make estimate, but it is not at all hard to find materials where ent will overestimate entropy. For instance, try estimate entropy of AES-CTR(128 x 0 bit, 1024 x 0 bit). This input has around zero bits of input, but ent will estimate it to have nearly 1024.
I would almost say that if you cannot indicate what the input material is (unfortunately commonly the case), and you feel ent or compression are good enough, you're very likely to end up with system that is not very strong (because you most likely will overestimate entropy).
