Another bug which could give you pops:
You have the timer set for a second, and in each event you generate exactly the samples needed for a second.
The problem is that the timer does not work like that. It won't trigger exactly every second. Think of it less like a metronome and more like a "wait one second, then get back to me as soon as there is some CPU time to spare". It will never take less than a second, but it may be slightly more. Also, the timer event itself will consume some time (you are looping 11025 times, doing some trigonometry then feeding a sample into the AudioStreamer each iteration, that is not instantaneous).
So, you'll need to generate a few more samples, so that there is some buffer left the next time the timer fires. I can't access the AudioStreamer methods/properties right now, but I assume there is some event in it to tell you how much data it has buffered. I would probably recommend that, instead of simply clocking out exactly 1 seconds worth of samples each timer event, you should clock out so that the buffer contains maybe 1.2 seconds worth of samples, to ensure you never "run dry".
Also, you don't keep a counter between timer events. This means that the wave might, in the worst case, end at the top value in one timer cycle, then restart next timer cycle at 0. That will give a nasty pop. You need to pick up where you left off.
Another thing: Sin is slow, as is converting floats to integers. If you just do it a little, no problem, but you do it 11025 times a second, and it adds up. Consider pre-generating a lookup table for Sin values at program start. If you are even smarter, you make that lookup table so that the results are already multiplied with 32767, which allows you to both skip the float step and an unnecessary multiplication. You could even take it one step further a pre-calculate the bit operations as well into the table.
Since you need integers in the lookup table, we can multiply the value I've called t in my code below with some integer to get a sufficiently high resolution suitable for our table (I used 1000). As a positive side effect, we don't need t to be a float.
You also recalculate the same things over and over in the loop, things which could be done outside it. I did that and stored it in t in my example. Viola, you've saved another 33075 calculations a second, 2/3 of them divisions.
You would get something like (snipped to the relevant bits):
dim t as int= 1000 * 2 * cPI / (sampleRate / Frequency)
For i = 0To numSamples - 1
dim f as int = t * i
snd(i * 2) = SinTable(f)
snd(i * 2 + 1) = SinTable2(f)
Next
I think this code will run at least 10 times faster, possible 100 times or more faster, and also save a lot of battery.
You'll have to figure out how to precalculate the tables yourself, though. I don't have time to do it now.
I would like a way to listen to samples while I create them: the only way is still choose a time interval, generate the samples for that interval, and listen to the sound of those samples in that interval, and so on in a loop.
So, in the timer, don't just slam the frequency to the new frequency. Remember the old frequency and then ease into the new when you generate the samples.
For example, in each timer event, gradually change the frequency from the old to the new freq, over all the samples you generate. So, say the old freq is 5 kHz and the new is 6 kHz. Then you would gradually ramp up the freq, so that, for example, halfway through, you would be at 5.5 kHz.