Right now we only use complementary mode. But nothing stops developers from running PWM on one pin and something like basic bit-banged sound effects on the other pin.
Even the very earliest Arduboy prototypes had a dual sound pins, potentially with completely independent outputs.
I don’t think only running one pin of the two is going to be a viable solution.
If I do it right, it wont add any delay but if I spend more than 2 weeks doing this then for sure it will be a problem.
“A late game is only late until it ships. A bad game is bad until the end of time.” --Shigeru Miyamoto
Actually even with the new library, single sided drive should be fine. The dual driving allowed for differential signaling which theoretically gives more volume and better quality.
We have tried all sorts of different peizo and even traditional speakers with coils. They all basically sound the same. We do lose about half of the volume by going without an optimized chamber like the one on the dev kit, but with an amplifier we should be able to get it 10 times louder or more.
This IC linked above is rated for 2.5W!!! That’s probably loud enough to hear from across the room.
Basically this new music is going to make people fall in love with their Arduboy. But right now, any type of speaker I put on there is too quiet. The best possible enclosure is only just barely audible.
I mean, this is like the most basic thing to solve, I’m in the middle of electronics capitol of the world. If I can’t amplify a speaker within 2 weeks here in Shenzhen I should probably just give up and go home! 
I’m gonna do a survey tomorrow just so I make sure that I’m doing the right thing for the community.
Maybe you should be asking people if the chambered speaker used on the Dev Kit is loud enough, and if so, use it. Wouldn’t that be easier and possibly less costly than adding an amplifier circuit? It would probably draw less power, thus increasing battery life, as well.
You could put it in the spot about where it is on the Dev Kit, above the A and B buttons, where the logo is on the production samples. Put some holes in the case above it and move the logo to the space below the buttons.
Have you tried various acoustic resonators and chambers? I’ve got a standard 18mm piezo element mounted on the cut off bottom of a single serving yoghurt cup, using double sided tape, for my home made system. It’s way to loud for my liking. I’ve added a 10k resistor in series to bring the volume down to something reasonable.
You wouldn’t be able to fit something this large in the Arduboy but a smaller properly engineered resonating surface may do the trick.
But you wouldn’t get the dual volume capability that you could get using two pins, by running either single ended or complimentary. Depending on the speaker circuit load impedance, there’s also the possibility of a low volume mode, by setting one pin to input pullup mode and driving the other pin.
However, if you do end up deciding to add an amplifier, then you might also be able to incorporate a true volume control. Use one I/O pin to drive the amplifier and another PWM capable pin, with a proper low pass filter, to output a volume control voltage to the amp.
IMHO the sound on the DevKit was louder than you’d normally want. Certainly more than sufficient. @bateske why the late change to a piezo disc? It doesn’t save any space, so I presume cost?
+1 for quickest solution to get Gen 1.0 product shipped to KS backers. Ideally just go back to the original tried and tested part…
This is all in response to the new sound driver that STG and @JO3RI put together. The volume is not enough, you can only hear it if you hold it up to your ear.
The normal tone library and other music we had before was fine.
There is some key to the chamber, as this will primarily dictate the frequency response and the perceived volume. I’ve tested a neat little trick to put some through holes in the pcb that seems to work as good as the chamber that is on the dev kit.
I went to the market yesterday and literally tested every different possible piezo configuration. Some were more-or-less the correct volume but were huge enclosures.
It’s looking like even just a simple transistor may be enough to get where we need to be.
And the change was made because of both cost and placement of the logo, but such things tend to happen with products.
I really appreciate the patience and even more the support. The main reason I use the royal WE in here and on the kickstarter is because of the development community. My fellow co-workers at HAX office are jealous that you are all so active on the development of the product. So thanks for all the help!
You’ll have to be careful then. If you boost the volume for the STG and @JO3RI driver, any games using normal tones and other music may “blow people’s ears off”.
Keep in mind that, if the library is done properly, the STG/JO3RI driver won’t be compiled if it’s not used in a sketch, thus leaving more space available for application code. Some developers may decide to use simple square wave tones for their sound, to gain more code space, or just because that’s the kind of sound that they want.
Has it been considered there might be a logic error in the library that effects volume?
Correct me if I’m wrong but if we use the differential driver then driving with only one pin using standard libraries will be half volume?
The key will be to balance the circuit so its just loud enough but not too loud.
This is a legitimate concern.
If the high-frequency PWM is driving to the voltage rails, then it should be able to generate voltage swings as high as an audio band PWM.
I realize you can’t actually fit a speaker in the Arduboy, but it would be informative to try one of the micro 8-ohm speakers with the various types of sound libraries. If the variation goes away while driving a speaker, that would suggest the difference is due to some feature of your piezo sounder.
Finally, one key feature of a high-frequency PWM module is the ease of making volume changes. It would be wise to be certain that the library that seems too soft doesn’t have a volume setting buried somewhere that has been set to less that unity (full volume).
If you have a detailed level of control, try setting up an audio band square wave PWM at several useful audio frequencies, scattered between 200 HZ and 5000 Hz - the main hearing band. Then use the high-frequency PWM library to produce square waves at the same frequencies. Electrically, the results should be identical. Thus, so should the sound. If they are still different, it’s time to break out the oscilloscope and check output drive levels.
If the square wave sound is the same, but other high-frequency samples are different, then you may be facing a difference problem - namely, that sound loudness is usually proportional to RMS power. Square waves (and audio PWM source) have about 40% more RMS power than an equivalent frequency sine wave (hi-freq PWM sources) , and as a result, will always sound louder. (They will also sound different.)
If that’s what you are encountering, then you have a tough decision to make, because no one solution will give you a consistent audio level between the two types of sources. If the audio PWM is fine, then hi-freq PWM will be lower. If hi-freq PWM is fine, then audio PWM risks being too loud.
I realize that the hi-freq PWM will generate nicer sound - it’s engineered to do that! But hi-freq PWM has to usually use pre-calculated sine wave tables. Those typically drive up the size of the library. That’s a key reason for people looking at this to know how much memory that audio driver takes from program memory and from RAM. Some programs may happily devote that space to the sound library, while other programs might need every last byte of program space they can scrounge for their code and screen data.
If you are going to do a survey, at least include all the relevant information so that any decisions are made while aware of the possible trade-offs.
You can indeed change the volume in the Squawk_TEAMarg library by modifying this line in Squawk.cpp:
// Reset volume
if(ix_period & 0x80) p_osc->vol = p_fxm->volume = 0x20;
Setting it to 0x40 will double the volume, but you will already hear a little bit of saturation when the 4 channels are playing at the same time. That is to be expected: the more channels you have, the less volume each channel must be, which is our problem… but maybe also our solution?
It will give half the voltage swing but that may not result in half the volume. A recording of the result of an experiment I did, shifting between single sided and complimentary outputs of square wave tones, can be heard here. More details are in this post.
Note that this result is for the particular piezo speaker and resonator (bottom of a yoghurt cup) that I used. This may not be the same for other speaker circuits.
And also from CPU load/cycles/overhead.
I set this to 0x80
And then:
Squawk.tune(4);
And the volume is great but sounds very distorted, could this be fixed?
How about if we modify the library so the user can set the volume parameter dynamically at any time? It could then be set based on the number of channels used, desired volume, distortion tolerance, etc.
The user should also be able to set either single ended or complimentary pin drive. Are we currently using complimentary output, or has it been tried?
It may be part of a programmers job to do sound design that keeps channel saturation and volume balanced.
However, would it be possible to watch any available channels for activity and attenuate the volume when the channel activity is high? This way the libs actively and dynamically do a little level boost when the hardware allows it?
It’s not really meant to be a sound api for a game, but rather a library to produce mixes.
