The example is okay with the noToneAC() to reset the registers.Try to remove the noToneAC(), that results in gaps in the sound.Perhaps the counter has to roll-over ?

I heard something like this once, but couldn't duplicate it so I figured I just had a loose connection.

You're exactly correct on your diagnosis. The counter is "over the top" so it needs to wrap before resuming the sound. This isn't very long when using prescaler 1. But, at 122 Hz and below, prescaler 256 is used which is 256 times longer than prescaler 1 and the reason for the long silence.

Since even more problems can happen when we play notes on each side of the prescaler cutoff frequency, I tweaked your sketch to create a torture test:

Since it includes frequencies above 122Hz, it sometimes also uses prescaler 1. Also, there's no delay so it just hammers the hell of of things. This sketch should produce a static-like noise as it plays random notes as fast as it can. Instead, it's a bunch of random clicks with periods of silence as it frequently goes "over the top".

After some testing, I've isolated the problem and have a fix. In the toneAC.cpp file after the line that reads "ICR1 = top;" add the following line:

With this, the above sketch now produces what you'd expect, static. During early development, I set TCNT1 = 0 when starting a tone. That works fine for high frequencies, but poorly at lower frequencies and when changing notes (creates clicks). It's even worse when driving a two-pin dual LED at ultra low frequencies (like at 2 Hz). Adding the noToneAC() in your sketch works because when TCCR1A resets the PWM it automatically sets the counter to zero. While this works, it's not ideal for the above reasons of setting the counter to zero can cause other problems.

In any case, the above line fixes things and I've added it to the development version which will be released in version 1.2.

On a side note, the volume setting doesn't really work well for low frequencies. It doesn't do much to change the volume and lowers the quality (makes it buzzy). I'd suggest to always use 10 for the volume, which keeps the quality high. Only use a lower volume if it's a requirement.

Anyway, thanks for the catch! And leading me in the right direction with the fix.

First of all, I love the library. It will be my first choice in most applications.I hope to test the Uno/Mega/Leonardo/ATmega8 with version 1.2, after that it should be ready.That single line of code makes some of my tests sound a lot better.

I have made a checklist for version 1.2, perhaps there are one to two things that make sense.

(1) The code increased a little (just a little) which is always a problem for the ATmega8library + example version with 1.0, Arduino Uno : 1516library + example version with 1.1, Arduino Uno : 1670library + example version with 1.0, ATmega8 : 1336library + example version with 1.1, ATmega8 : 1472

(2) The ISR uses millis(), so a roll-over of the millis is possible. The length is no longer fail-safe, so using the delay() function with noToneAC() is preferrable for critical situations.

(3) You don't use the 'L' for long values. I don't mind about it in the sketch, but you could use it in your library. I prefer to use 0L, 256L, - 1L and so on, when long integers are involved.

(4) The examples have the extension *.pde. I would prefer *.ino

(5) In the example you use '/* .... */' for comment, but everwhere else '//'.

(6) In the example, you use a potmeter. But for a small test with the library, a very quick result (showcase) would be needed. And a potmeter will make it unnecessary complicated.

(7) You made 10 volume steps, which is great. But for a 'ping' sound, a smooth decrease of the volume is needed. Or am I asking too much for the library ? Are there open source examples of tunes with volume ?

(1) The code increased a little (just a little) which is always a problem for the ATmega8

Great pains have been taken to keep the code as small as possible. I'm a huge believer in running as much as possible in the background so around 150 additional bytes I believe are important. It's still much smaller than the tone library. I show the Arduino Uno code to be 1604 bytes with Arduino v1.0.2 not 1670. And with the ATmega8 I have it as 1398 instead of 1472 (again v1.0.2). As a test I created a toneACmini() function that only has a frequency and duration (automatically runs in the background). With toneACmini() instead of toneAC() it went down to 1488 bytes on the Uno. But, not sure if 116 bytes is worth confusing people.

(2) The ISR uses millis(), so a roll-over of the millis is possible. The length is no longer fail-safe, so using the delay() function with noToneAC() is preferrable for critical situations.

It uses unsigned long int, so it's about a 50 day range. That should be good for almost any situation. The rollover of micros is critical, but ms hardly ever happens in the real world. Although, I am working on a project right now that I'm trying to get it to run virtually forever.

They need to be .ino for a library so old versions of Arduino can find them. I'm running only v1.0.2 so everything is a .pde. I change them to .ino just for the library. Other library creators told me to use .ino

(6) In the example, you use a potmeter. But for a small test with the library, a very quick result (showcase) would be needed. And a potmeter will make it unnecessary complicated.

The library is designed for sound, not LEDs. The sample is "toneAC_demo" which doesn't use a pot. The one you're talking about is an advanced one that I don't mention anywhere as it's only for more advanced users that may want to use toneAC for other purposes.

(7) You made 10 volume steps, which is great. But for a 'ping' sound, a smooth decrease of the volume is needed. Or am I asking too much for the library ? Are there open source examples of tunes with volume ?

You're asking too much. I got out my SPL meter and it was HARD to get even 10 volume levels. A square wave just doesn't work well for creating a true volume level. I had to cheat to get even 10, there was really only 9 but that would just be confusing.

They're very close. But, the first loop is inferior because it uses the foreground method and therefore there's a short period of time where there's no sound, producing a non-constant sound and clicking. This way is designed for a laymen who who isn't too comfortable with programming but they can still generate sound using this method and would probably be totally happy with that. The second way is a more proper way that a higher level programmer would use, knowing that the first way would have a very slight but still noticeable gap between notes reducing quality. I would only ever use the second loop, as I did with the original tone() library as well.

The idea that something runs in the background is very foreign to many novice programmers. They love delay statements, or a command that just does something for as long as they specify and then returns to them when it's done. So, toneAC makes it easy for the masses, but still powerful for those who better understand an interrupt/timer driven paradigm.

If you want a loud alert from a piezo, it's best to first find its harmonic frequency. You can do it with a miltimeter. Just look for the frequency where the most current is drawn. It will typically be quite a large spike right at the loudest point. If you want something loud, this will be the frequency to play. With a piezo, it's typically 4,000 Hz.

To save a bit of compiled code size, use toneAC(). instead of noToneAC(). noToneAC() was meant to be familiar to the Tone library and the noTone() command. But, it's totally not needed for toneAC() and as a bonus you save 10 bytes.

Also, I created a TONEAC_TINY switch that allows you to save around 110 bytes that uses an alternate version of toneAC(). Would be useful for projects where maximum speed or the lowest code size is required.

I'm considering creating another library named something like ToneTiny or NewTone where it's a plug-in replacement for Tone including pin assignment but is much smaller, faster, and better quality. I know lots of people that have timer interrupt issues with the Tone library and are looking for an alternative. Not that toneAC doesn't provide that already, but toneAC is designed more for highly accurate AC switching speed and maximum volume.

I'm considering creating another library named something like ToneTiny or NewTone where it's a plug-in replacement for Tone including pin assignment but is much smaller, faster, and better quality. I know lots of people that have timer interrupt issues with the Tone library and are looking for an alternative. Not that toneAC doesn't provide that already, but toneAC is designed more for highly accurate AC switching speed and maximum volume.

It was so easy I just did it, NewTone is a working library. Plug-in replacement for the Tone library, but over 1,200 bytes smaller compiled code size, faster, better quality sound, etc. Also uses timer 1 if you're having a conflict on timer 2 with the Tone library and some other library or hardware. Seriously took 30 minutes to write.

A little bit surprising is that toneAC still produces slightly smaller code (60-170 bytes). This is possible because toneAC doesn't need to find the ports and masks for the pins as it's fixed. But, I believe NewTone still has a place for those who need smaller, tighter code, yet need the flexibility of connecting to any pin. toneAC is still better in every way, with the exception being the fixed pins, but that's also why it's so good.

I'll probably package up NewTone and upload it later today for those who need a flexible drop-in replacement for the Tone library.

I tried your sketch on a Bobuino with a 1284 chip, the speaker buzzed but nothing more. The board is found halfway down this page. http://www.crossroadsfencing.com/BobuinoRev17/

This may be asking too much but, would you consider making your library work with the 1284P? I have built a few boards using the chip.

This page may help you in the process if your interested. http://maniacbug.wordpress.com/2011/11/27/arduino-on-atmega1284p-4/

I will be happy to test for you of course.

I had believed it would work with the 1284P. Don't have one to confirm, but looking into it further I see that the ATmega1284P is different. I've updated my development v1.2 to support ATmega640, ATmega644, ATmega1281, ATmega1284P and ATmega2561. I've private messaged you a file for you to test to verify it works on the ATmega1284P. The pins you should use are D12 and D13 (the timer 1 PWM pins) on that microcontroller.