karargah66,
Grumpy_Mike is right-you need a scope. I use a sensitive digital VOM, a quiet power supply, and an oscilloscope to do frequency detection with FFT/FHT, and I can tell you that you will not pick up 440Hz on that tiny cheap microphone as easily as higher frequencies. It's very small and cheap. An amplifier-even if not frequency/band specific/discriminating-will boost the lower frequencies, to be sure, but also a lot of low-frequency noise. You can't have it all, so you may need to change your parameters/requirements to suit your needs.
With a scope [with built in FFT] you can tell everything you need to see/know/adjust to make it sensitive-even discriminative-to 440Hz. One problem you won't see without one, I can tell you from experience, is frequency error. FFT 'windowing' modes have their benefits and weaknesses, but even the most frequency accurate modes are not perfect. If you find a good combination of samples/s, bins, etc. for your processor, you will then need to deal with frequency offset to convert a bin (frequency) reading into the actual (or closest) frequency. I have found that FFT accuracy in the frequency domain varies wildly, and far from linearly.
You can't just plug a number in to add/subtract from and think it will work. I am doing vaguely similar work, and I can tell you the best you can hope for. You can select a range of bins that bound your target frequency, and measure the spl at those places against background. But it is at this point in your testing that you will come across your next dilemma: Background threshold. One surprise I found was that with a 'calm' white/pink/brown background, a tone stood out nicely; But as soon as I did something like speak, the FFT signal level output of a tone's signal dropped. You'll find your signal discrimination ability will vary significantly based on the kind of environmental noise you'll have in real life. I'd suggest you record & play back in your lab the kind of background noise/sounds you expect-and at the level you anticipate them to be at. Everything works perfectly on the bench! 
It's one thing to measure the spl of a bin as the output of the standard FFT libraries for arduino out there. It is an entirely different matter to determine how much 'louder' that signal is than background. You might want to look at the math in FFT/FHT to understand why a tone stands out in your output. Here is a glimpse into the problems I've uncovered, in hopes you & others can benefit:
-You will find it non-trivial to calculate the bg (background) noise level. Just adding up all the bins & dividing by the # of bins for the mean won't do. For openers, what frequency range(s)?
-If you have 'spikes' in your signal (which you will have with tones), a careless count of levels includes these, and the tone signals are much higher that the bg. Do you them subtract the highest signal? What about 2 simultaneous tones (as in many of my own works' examples)? Harmonics?
-Another problem with the bg is that the s/n ratio (with noise defined as the bg) is not the same at all signal levels (a scope proves this out well). When you read relative values of 1, 2, 5, ... for bg, the signal may be only a few integers higher. But when the noise is higher, the differences become much greater by orders of magnitude.
-CPU: Like I said above, nothing is free. more bins, more samples, more X all require more CPU cycles per second. Without it, not only are your bins sitting on chunks of signal (wide instead of narrow), but you will find the level of a spike in the range of a bin will be averaged with the noise in it's 'range', thus making discrimination more difficult, as no one bin will really stand out among the rest. Think of this like averaging your single peak with 100 lower level signals in the bg. Now average the same peak with just 5 bg signals. The former will be a low signal, not representing the peak's actual value, but the latter might be usable.
-If you want discrimination, you need lots of bins, so each bin looks at a narrow frequency range. Lots of bins means lots of computations, and you will hit a brick wall fast at 16MHz. I'm not developing remote sensors on ESP8266 running at 160MHz, and the results are passable, but all those bg calculations and discrimination/FFT math comes at a cost, too.
I am currently working on refining the windowing mode to use with the bg/discrimination math being as easy on the processor as possible. If I can simplify the code, I can run more samples/second. So to summarize, these are the variables/considerations:
-Test equipment (that pot does affect the output, but your ear isn't sensitive enough to pick it up-meters are).
-Frequency accuracy.
-Microphone quality.
-Low noise amplification (in this case, noise isn't background, but actual noise (unwanted, generated signals) as a result of amplification.
-Directional guides to let the mic(s) point more toward the signal source, and pick up less unwanted background.
-Processing power, which is directly proportional to quality of output used to control/signal.
-Price. Without you saying your budget, you leave a lot open to assumptions.
Good, Fast(Easy), or Cheap-pick one...
P.S. Beware of AGC... I found in most cases for my use (tone detection), it lowered higher (desired) signals and raised the level of lower (undesired) signals-which it what AGS and compressors do. Added to this is that in my tests the compression was not immediate, so signals that were actually at a static spl were raised/lowered noticeably. You may want to get your rig refined without one (let louds be loud, quiets be quiet), and only then decide if adding compression is an improvement.
