Short answer: the acceptable password hashes are bcrypt, scrypt, or PBKDF2. In all likelihood, anything that isn't one of those three gets you in the news for losing passwords when your site gets hacked.
HMAC is a construction that takes a hash (like SHA1), data, and a secret key (like "ff79f2fbe108a68c34a66004058fcfdb988dbc43") and applies the hash twice, each with a special tweak, to create a digest that only someone who knows the key can recreate from the same data. It's how two parties who share a key can prove to each other that their messages haven't been tampered with.
Hash+salt is a construction that takes a hash (like SHA1), a password (like "gobears") and a random public value (like "$4jdle$") and creates a password hash out of it that can't be precomputed.
People do (ab)use HMAC as a password hash. Those people should know that HMAC is as easy to precompute as naked SHA1 is; you can "rainbow-table" HMAC. People who have misunderstood HMAC tend to stick up for it by saying "yeah, but people will have to find my secret key first", to which a response that ends that silly argument is "once they get your key, they can attack all your hashes in parallel and that's bad".
All of these schemes are demonstrably inferior to any adaptive hashing scheme, like bcrypt or scrypt or PBKDF2, all of which can be tuned so that a single password attempt takes 500ms (or any other time); they in effect require password crackers to complete a "proof of work" that can't be sped up without a breakthrough in cryptanalysis.
Some day, and that day may never come, I'll call upon you to explain cellular respiration to me.