Audio Library

Status
Not open for further replies.
I'm planning to edit all the examples later today, to add comments at the top in a style similar to Arduino's examples.

Unless anyone objects, I'm going to copy Arduino's 1-line "This example code is in the public domain" permission.
 
In examples/PlayMidiTones the file william_tell_overture.c is not used and MIDI is not used. It looks as if this started as an example to use MIDI and then developed into something else.

I suggest moving PlayMidiTones.h and PlayMidiTones.ino into a new directory, say examples/PlayToneRamp and calling them PlayToneRamp.h and PlayToneRamp.ino

It would be nice to have a PlayMidiTones example which read a MIDI stream from USB and then played the notes on the audio shield. I might write such an example (but don't hold your breath).
 
PaulStoffregen said:
I'm planning to edit all the examples later today, to add comments at the top in a style similar to Arduino's examples.

Unless anyone objects, I'm going to copy Arduino's 1-line "This example code is in the public domain" permission.
Click to expand...

I don't object but do suggest being more precise; the definition of public domain varies by country. A Creative Commons 0 Public Domain Dedication provides that definition in a concise way. See https://creativecommons.org/publicdomain/zero/1.0/

"This example code is in the public domain (CC0 1.0)"
 
@Nantonos: Are you referring to the most recent version of the Audio library? The original PlayMidiTones example didn't use the notes table. I modified it so that it did play the William Tell Overture from the william_tell_overture.c file as a demo of how using ramping removes the thump at the start and end of each note.
I agree that the example has nothing to do with MIDI though and the name could/should be changed.

Pete
 
I agree, it's become clear the use of "MIDI" in the name suggests it would receive real-time MIDI data. I will write an example that does such a thing (well, unless someone else beats me to it).

First I want to work on a proper envelop object with a proper attack-decay-sustain-release profile. I'll probably move the ramp stuff to a similar stand-alone object.

The data file is created by a program called "minitones" that converts a MIDI file into that array. At the time is seemed reasonable to name the example based on the name of the program that created the table, but now it's become pretty obvious that wasn't such a great decision.
 
Nantonos said:
I don't object but do suggest being more precise; the definition of public domain varies by country. A Creative Commons 0 Public Domain Dedication provides that definition in a concise way. See https://creativecommons.org/publicdomain/zero/1.0/

"This example code is in the public domain (CC0 1.0)"
Click to expand...

A few years ago, when Arduino updated the comments on all their examples, Tom Igoe (of the Arduino Team) made a very compelling argument for way they've done it. Tom has spent an incredible amount of time teaching beginners and had a tremendous amount of first-hand experience watching what trips novices, which turns out to be pretty much any extra detail that's not absolutely essential for the example. Even tiny extra details can be a big distraction.

There was actually quite a bit of debate about this text. In the end, it was felt that the fairly unspecific public domain notice was adequate to convey permission to copy and use the code. I guess I'm feeling influenced by Tom's opinion that adding even small things like just 9 character like "(CC0 1.0)" adds complexity and distraction to what would otherwise be a very simple statement.

On the other hand, it is good to be clear and specific. Perhaps that goal could be achieved by a "COPYING.TXT" file in the library, which explains this statement in the examples means CC0 1.0?
 
If this has already gone through a round of discussion, agreement has been reached and you agree with the end result, then I'm fine with leaving it unspecified. I'm probably more influenced by my work where details of licenses and grants are important, and underspecified licences mean that content is dropped because it might be tainted.

A separate COPYING.TXT will in practice never be copied when people copy and modify the examples, so is more distracting than an inline CC0 mention.
 
Apologies, I was looking for a #include of william_tell_overture.c and missed the use of
Code: 
const unsigned char score []
 
Hey Paul, do you use Eagle?

If so, could you share the lib for the Hirose DM3D-SF MicroSD slot you're using on the audio module? I'm making a board that utilizes the DAC which I'd like to socket the Teensy into, and the Hirose is cheaper than the Molex one I've been using.
 
scswift said:
Other than the pops I was getting with certain songs, everything works great.
Click to expand...

I've just committed a fix for the WAV file end-of-data handling. I believe this should fix the click heard at the end of some files.

I tested with 001.WAV file you sent, so at least I can say for certain it works in that case!
 
I've added isPlaying(), positionMillis() and lengthMillis() to AudioPlaySdWav.

These can be used from your sketch to detect if the WAV file is still playing, and where in the file it's at.
 
Hi!
I've been working with the old single-file version of the library, and everything was working fine. I've just updated to the new splitted version, and I am having some problems.
I'm using the AudioOutputAnalog as output, and I assume the update() method is not getting called. I went back to a simple sketch to see if it is my code to create troubles, but the problem is still there. At the moment, I am connecting an AudioSynthToneSweep with the AudioOutputAnalog (basically, it is the AudioSynthToneSweep example with the on board dac as output). It goes in the begin() method of the AudioSynthToneSweep, but it seems it never goes into the update() method.

Am I doing something wrong?

Thank you,
Enrico
 
Thanks for your answers. I think I've found where is the problem. Everything works fine when I comment "dac.analogReference(INTERNAL);".
I had this line left since I was playing with the reference. Talking about this, what is the advantage of using 1.2V instead of 3.3V?

Thank you,
Enrico
 
saxen said:
Thanks for your answers. I think I've found where is the problem. Everything works fine when I comment "dac.analogReference(INTERNAL);".
I had this line left since I was playing with the reference. Talking about this, what is the advantage of using 1.2V instead of 3.3V?
Click to expand...

The advantage is if you're not using Vin then you bypass the chip's onboard 3.3v regulator and if there's noise in your 3.3v supply then it could impact the quality of your audio.

Also, 1.2v is very close to the .894v standard for line level on consumer audio, so you can avoid using a voltage divider on the output without worrying about messing with how much you can crank up the volume knob on your amp before it starts clipping.
 
I'd prefer it default to that. I can't think of any reason to have it default to 3.3v when using the audio library. But as long as we can set it, I'm good.

I do have a question about how we should go about using it though.

I noticed in the datasheet it says the max output load current is 1mA. Is that something we should be concerned about? If I connect that DAC to an amp, via a capacitor, is is possible charging and discharging said capacitor could exceed that rating and damage the chip? I was thinking about putting a 360 ohm capacitor on there just in case... when I thought the pin had a current limit of 9mA. But if it's 1mA and I assume that the voltage may at some point be set to 3.3v accidentally, then I'm looking at something more along the lines of at least 3300 ohms.

Am I misunderstanding the datasheet or being overcautious here? I'm concerned if I add a resistor I may end forming some kind of filter with the circuitry in the amp and filter out frequencies I want to keep.
 
That and several other files won't play for me either. One of my test files, which happens to be the longest one, does play. There doesn't seem to be a common denominator. The one that plays is 16-bit PCM 44.1kHz stereo but so is one of the others that won't play.
wav.play is not failing with those files so it is trying to play them.

Pete
 
scswift said:
The advantage is if you're not using Vin then you bypass the chip's onboard 3.3v regulator and if there's noise in your 3.3v supply then it could impact the quality of your audio.

Also, 1.2v is very close to the .894v standard for line level on consumer audio, so you can avoid using a voltage divider on the output without worrying about messing with how much you can crank up the volume knob on your amp before it starts clipping.
Click to expand...

Thank you! Now the question is, am I the only one having this problem with the latest version of the library? Based on what I've tested, I cannot set the internal reference...

Enrico
 
Status
Not open for further replies.
Back
Top