PDA

View Full Version : Audio For Teensy3 - What Features Would You Want?



PaulStoffregen
08-19-2013, 10:11 PM
Edit: The audio board for Teensy3 is now available:

http://www.pjrc.com/store/teensy3_audio.html



Recently I've started working on audio for Teensy 3.0. It's still in the early stages. My hope is to make an alpha release in late September.

In the meantime, I'd like to start a conversation about possible audio interface hardware PJRC might sell. This is your chance to weigh in regarding features vs cost... what should I put on the board that you'd find really useful, and what should I leave off to keep the physical size small and the cost lower?

For projects where you only need moderate quality, like you'd get with Adafruit's Wave Shield (http://www.adafruit.com/products/94) on Arduino Uno, the option will be there to get it from Teensy3 using only resistors and capacitors on PWM and analog input pins.

For 16 bit stereo at 44.1 kHz (roughly CD quality sound), of course a CODEC or DAC is needed. I'm looking at several options. All have stereo line level output. Most have the ability to drive headphones (33 ohm load). Nearly all CODECs can accept a signal from a electret condenser microphone, the same type you'd plug into the pink audio jack on a PC. These are pretty much the baseline features.

The first big choice, where I'd really like your input, is connectors! Connectors increase the cost moderately, but of course the circuit board would become much larger than a Teensy3 if it had 4 RCA jacks for line in and out, a green headphone jack & pink mic jack, and big terminal blocks to wire up speakers. How important is small size? Should I keep the circuit board approximately the same size as a Teensy3, even if that means not bringing out every possible signal, or cramming stuff like line-level in/out to 0.1 inch spaced pads?

Another big question is how important are stereo line level inputs? Or microphone input? An output-only DAC or a CODEC with stereo output but mono-only input might really reduce the cost. Should I consider this, or is stereo input really an essential feature?

Another option which I personally think I'd use is a built-in amp capable of about 1 watt to an 8 ohm speaker. Sure, you can always build another board for the amp, or use amplified PC speakers. But for a Teensy-sized project running from three AA batteries or a 3.7V Lion battery, having a highly efficient (class-D) amp that can be power managed via the I2C seems pretty useful. But amplified speaker output does add a few dollars, and more if it's capable of 2 speakers. Is that worthwhile, or just an unnecessary expense?

Adafruit's shield has a nice volume knob. All solutions I'm considering have software controlled analog volume adjustment. But I could add a pot that connects to an analog input, so your program could periodically read the knob position and adjust the volume. Again, it's a matter of extra board size and extra cost... so is that worthwhile, or should I just leave it off?

Maybe there's other audio hardware I've not considered? I'm open to feedback. I'd like to make something that will really be useful, so I'd really like to hear your opinions, especially on the trade-offs between features, physical size, and cost?

mxxx
08-20-2013, 06:32 AM
nice. my 2 cents would be this (depending on your target audience, of course, but from what you're writing it seems it's neither greeting cards makers nor DAC hifi craziness.)

as to connectors, keep it flexible. i can't speak for everyone but i'd imagine people using won't just simply stack it onto their teensy but probably will put it somewhere (in a box, behind a panel, etc) along with any pots, encoders or what have you, so why have onboard jacks if these - RCA, or phone jacks, or 1/4", or XLR - who knows - ultimately are going to sit somewhere else (the audio codec shield, for example, though nice enough, is physically too unwieldy, for my taste at least). in that case, it would also make it easier to further condition your signals (eg amplify beyond line level), ie without having to desolder jacks or the like.

another thing to consider, again depending on your target audience, is SRAM ... though that wouldn't exactly reduce costs, of course. i'm not sure where you're heading with your audio API, but i'd image that it would increase the usefulness considerably; after all, there's only so much you can do in between i and o without. it certainly would fill a niche (audiophiles can get their i2s DACs on ebay already, there's plenty of lo-fi mp3 shields, not everyone is into blackfins et al).

anyways, thanks for doing this! i'm especially curious what you come up with with the API, but that's probably not the thread to bring this up.

Ben
08-20-2013, 08:47 AM
Hi

Connectors:
None. Really. The connectors used in audio are to large. My Suggestion would be either solder pads/holes or small connectors that can be used with a short adapter cable.

Volume Knob:
I'd suggest a rotary encoder that can be pushed. Debouncing can be done in software i think.

Inputs:
Stereo line level is not important IMHO. I'd go for mono input. Instead of a microphone input I'd suggest a mic preamp (maybe with an option to add phantom power) with an option to route either a line level input or the mic amp to the CODECs input.

Outputs:
Well, I2S of course. Maybe S/PDIF would be a useful addition, CMOS-Level to attach an optical transmitter or consumer-level (which is 0.5Vpp IIRC). And unbalanced analog line level outputs.
Power Amp:

Other Hardware:
A micro SD slot would be excellent!

regards
ben

PaulStoffregen
08-20-2013, 10:44 AM
The ugly prototype on my desk today....

843

And a first attempt at a cleaner PCB with 2 jacks and a AC97 style header for line in & out.

http://www.oshpark.com/shared_projects/MQX1qj7Z

None of this is meant to be the final form.

Regarding the API and software, let's discuss that over on the other thread (http://forum.pjrc.com/threads/15748-Teensy3-I2S-with-DMA). It's all still at a pretty early stage of development, so there isn't a lot to tell at the moment.

This thread is really about the hardware, and specifically what trade-offs should PJRC make with features vs physical size vs cost.

CitrusTree
08-20-2013, 08:19 PM
I can't give too much input from a hardware point of view as I'm very new to all this. But... I've been a musician for 23 years and a (computer based) producer for 13 of those, so audio I can do!

For me, the ability to use stereo line level audio would be REALLY important. But this could (should?) be 2x mono... I can certainly see the value of having a microphone input for many projects, but for studio based projects my mind starts to go slightly crazy starting to think of all the options an easy access line level audio port would open up for me. As Ben said I would not be too concerned about selecting my own audio connector(s) so solder holes.

As for output - I'd probably say optical or sp/dif at this point as I could hook it straight into my desk with no D/A/D conversion going on. Actually, I could say that for input too, now I think about it!

Perhaps I'm not helping after all :)

rbrockman
08-21-2013, 05:14 AM
Audio is such a large and diverse world... I've been using Twisted Pear audio products for quite a few years now. Specifically, their DAC and linestage products are quite good. I've built a few different versions of each. You might get some good ideas here: http://www.twistedpearaudio.com/landing.aspx

If you are interested in audio signal processing and other i/o types of features check out MiniDSP - http://www.minidsp.com/products for more ideas.

Food for thought

MichaelMeissner
08-21-2013, 06:22 AM
Obviously this won't be for Teensy 3.0, but I suspect some transformations people want to do with sound are easier if the chip has hardware floating in it. If you were going to change processors for Teensy 4.0 to get floating point, you would probably want to keep the single cycle multiply and some vector integer multiply instructions, which is another thing often times used for audio processing.

sumotoy
08-21-2013, 09:34 PM
connector

I also quote to use empty pcb holes so It's easy solder a connector if needed. Audio connectors are too large and small ones are ok just for experimenting but nasty for a final project (think about boxing it)

volume knob
Don't know how much it's useful, but I will quote for a rotary encoder either.

outputs
Of course I2S is necessary, SPDIF useful too.

What I still not understand is if you want to use an audio codec chip, an interface chip or whatever! Audio codec chip have usually poor quality DACs, interface chip like wolfson are excellent in quality but has some small bug and need separate ADC/DAC, there's a really large amount of options, maybe too much to focus an hardware solution easily.
Maybe the best option is an audio codec for ready to go experiments with the ability to disable for add externally high quality ADC/DAC though I2S and SPI.
I have done a lot of experiments with DACs/ADCs and personally what I never got is an ADC with external audio clock that works without a massive jitter, I got close but have to use a FPGA and lots of pain...

Nantonos
08-21-2013, 09:42 PM
I would prefer that the board

a) concentrate on things which it can do well and which other people may find hard
b) leave off things which are easy and where there are many different choices
c) avoid getting in the way or blocking off useful options
d) design for expandability

Since it is easier to discuss a concrete example I'm going to pick a board that I ordered a couple of and found dissapointing, and explain why. Have a look at audio codec board (http://www.mikroe.com/add-on-boards/audio-voice/audio-codec-proto/) from MikroElectronika
(linked from http://www.mikroe.com/add-on-boards/audio-voice/ whichhas a variety of audio boards useful for comparison)

Here is the board description, mostly copied from the codec itself:

The on-board Audio Codec WM8731 provides stereo line and mono microphone level audio inputs. This module also uses stereo 24-bit multi-bit sigma delta ADCs and DACs with oversampling digital interpolation and decimation filters. Stereo audio outputs are buffered for driving headphones from a programmable volume control. Line level outputs are also provided along with anti-thump mute and power up/down circuitry.
and here is the reality:
one third of the board space is taken up by soldered-in mic and headphone connectors. The chip does indeed provide stereo line in and stereo line out but the board does not expose them. Not even some pads on the edge; if you want to access those, you need to solder directly onto the pins of the small, surface mount chip which is made harder by nearby components. Instead, the board gives access to the (mono) mic in and the (stereo) headphone outs, only.

Conclusions - avoid hiding features. Make expansion easy. An audio connector is two wires and takes space so please let people select and connect their own. Same for lofi speakers and lopower amps and such - these things are very widely available and easy to connect. One size does not fit all, let people select and connect what they want here.

That codec (http://www.wolfsonmicro.com/products/audio_hubs/WM8731/) would make the basis for a great "audio for teensy" board, if the features were exposed, the connectors dropped, and maybe a couple of adjustable gain smd op-amp buffer stages added in as well.

As an example of making expansion easy - if the eventual board was mono, and if it had digital control over volume, then having a pair of pads that let you connect two boards and get stereo volume and balance would be neat.

PaulStoffregen
08-21-2013, 10:03 PM
So far, there seems to be 2 common themes:

1: One size does not fit all, maybe not even most?

2: Every available input & output option must at least come to solder pads.

On point #2, I'm using that same MikroElektronika board for prototyping. As you can see in the photo above (reply #4) I've already had to desolder the crystal, because it didn't provide a way to run in slave mode, and I've added a wire soldered to the side of one of those big capacitors, since it didn't provide the output at a pad or any other place where I could clip a scope probe.

Teensy 3.0 has I2S. If you want direct digital audio and you can use I2S, the pins are:



TXD 22
RXD 13
BCLK 9
LRCLK 23
MCLK 11


Two of these conflict with the SPI port. I'm working on an extension to the SPI and SD library, which will appear in Teensyduino 1.16, to easily reassign the SPI signals to their alternate pins.

For S/PDIF and analog audio, of course a interface or dac/codec chip that takes I2S is needed.

I'm starting to think this might need to be 2 or 3 different boards. I'll probably make a low-cost board first, with line level stereo in and out and amplified output for headphones. It will very likely have a single 3.5mm jack, even though that adds to the size, because for just trying things out it's extremely convenient to be able to just plug headphone in.

I'll probably make a couple others boards to try S/PDIF and an audiophile quality DAC. These might be just DIY boards, maybe even just order the bare board from OSH Park, parts from Mouser and solder it yourself.

mxxx
08-21-2013, 11:36 PM
.. for just trying things out it's extremely convenient to be able to just plug headphone in.

no question, but one thing worth considering is that for just trying things out, things like that mikroe/wolfson board, or even some 12 bit dac shield, basically are around already. at the other end of the extreme are dsp development boards, but there's nothing, or little (i know of), in between, save certain dspics maybe. nor are these existing things typically very suited - connectors would be one example, buffering/amp stages another (not too mention form factors) - to actually be put in a usable design/device, which is, i guess, one of the strengths of the teensy and what i take a lot of the people here were getting at when asking for connectors being exposed etc.

i'm guessing specific needs are best served by coming up with one's own pcbs, but there also seems to be room for some kind of slightly more advanced audio (or dsp) shield*, which perhaps wouldn't be a matter of AD/DA only but also of memory (sd card / sram), op amps, power (rail to rail/single supply), etc, options. (i'm not saying i know how such a thing would look like, let alone how it could be made to fit everyone's needs).

* interesting project, for example, in this direction seems to be this - http://hoxtonowl.com/hardware/specification/ - though unfortunately, unless you are into that kind of thing, very much geared towards being a guitar effects thing.

daperl
08-21-2013, 11:47 PM
Teensy 3.0 has I2S. If you want direct digital audio and you can use I2S, the pins are:



TXD 22
RXD 13
BCLK 9
LRCLK 23
MCLK 11


I thought transmit and receive had their own set of pins. Can transmit and receive use the same BCLK and LRCLK pins?

PaulStoffregen
08-22-2013, 12:19 AM
There are many possible I2S configurations. However, I'm planning to support only 2 in Teensyduino: transmit-only using 4 pins and receive+transmit using 5 pins. The clocks are shared in receive+transmit mode. In both modes, all 3 clock pins are outputs from Teensy3, so whatever DAC or CODEC you use must be configured in slave mode, to receive all the clocks from Teensy3.

Edit: Most CODEC chips require shared clocks, so this 5 wire configuration is the only way that works with many of those chips. If you build a system with a separate DAC and ADC, it's perfectly fine to run the 3 clock signals to both chips, and of course the RXD pin to only the ADC and TXD to only the DAC.

Edit again: MCLK will always be created in 256*fs mode, which is by far the most common mode compatible with nearly all audio DACs and ADCs.

tni
08-22-2013, 07:34 AM
I'm not convinced having the Teensy provide the master clock is a good idea. E.g., if you look at the WM8731 datasheet, it needs a clock with less than 1ns jitter. The K20 I2S can use an external clock - any reason not to do that?

There are quite a few DAC boards with I2S out there, what do you want to do better than them?

I would prefer to see a Bluetooth Teensy over an audio board, which is even somewhat relevant to this thread, since it could drive Bluetooth speakers.

PaulStoffregen
08-22-2013, 12:29 PM
The K20 I2S can use an external clock - any reason not to do that?

The main issue is clock synchronization. The audio API will provide the ability to connect audio streams from many different types of objects, most of which are sync'd to the Teensy3 system clock. This system is intended to make building really interesting audio applications very simple, but to achieve that easy compatibility, all samples rates must be in sync.

Perhaps at some point, someone (maybe even me) might create an alternate I2S object that supports external clocking. But it will need to deal with the asynchronous relationship between the 2 sample rates. That's certainly possible, and in theory just a small matter of programming. However, in practice, someone needs to put the work in. At least in the forseeable future, the software layer will require all audio objects to be in sync.

Currently I'm generating MCLK from the system clock, which is based on the 16 MHz crystal multiplied by the on-chip PLL. The Teensy3 PLL probably isn't as good as the one inside that Codec chip. Then again, I'd be pretty amazed if a low-cost Codec chip like the WM8731 had a really great PLL. They mention their crystal oscillator is great, but that applies to pretty much all crystal oscillators, unless you do something really wrong like couple digital signals to the sensitive crystal signals (as Arduino Uno R2 did). In real systems jitter comes usually comes from noise sources in the PLL.

Wolfson doesn't give any specs on their WM8731 PLL, or even mention its jitter performance. If you read the WM8731 datasheet's "Test Conditions" above each set of specs, you'll see absolutely every audio performance parameter is specified only in slave mode. Presumably they're testing with a virtually perfect MCLK. When reading datasheets, the gotchas are almost always the things they don't mention (datasheets are written by marketing departments with one and only one goal, which is to sell you the part). I may be a bit too cynical, but I've been burned countless times by datasheets that only specified a part in one way, so when they don't give any specs at all for the other mode, I tend to assume that means it doesn't perform nearly as well.

I haven't looked at every part of the WM8731 datasheet and configuration. But if the chip has the ability to not use its PLL and if you use a 11.2896 MHz crystal, I would imagine it would probably perform very well (but still, that's just guesswork.... since the chip has no specs at all for master mode).

So, back to slave mode.... Teensy3 has an option, which I'm going to try soon, to generate MCLK by fractional dividing the direct (well, buffered) crystal oscillator output, without going through the PLL. If that works, odds are it should have very low jitter.

But even using the PLL might not be so bad. Looking at the Freescale datasheet, there are jitter specs for the PLL, at 48 and 100 MHz. Teensy3 runs the PLL at 96 MHz, which is pretty close to 100 (and the 100 MHz specs are much better than the 48 MHz ones). The datasheet claims 50 ps of "PLL period jitter (RMS)" and 600 ps of "PLL accumulated jitter over 1Ás (RMS)", in section 6.3.1, pages 26-27. A footnote warns "This specification was obtained using a Freescale developed PCB. PLL jitter is dependent on the noise characteristics of each PCB and results will vary". Freescale also specifies RMS measurement. Wolfson's "clocks with less than approximately 1ns of jitter to maintain performance" recommendation isn't clear (at least to me) if they mean RMS or peak or something else. So while 600 ps seems pretty comforting compared to the 1 ns recommendation, I am concerned about jitter.

But my primary design goal is providing an API that makes audio extremely easy. Systems like MAX/MSP and Puredata do that on PC-class computers. I want to bring that to microcontrollers with the sort of extremely simple and easy interface you'd expect from using Arduino. I need the sample rates synchronous with the processor clock to do that.




There are quite a few DAC boards with I2S out there, what do you want to do better than them?


Well, that's a good question. Certainly you can use any DAC or Codec board, or make your own.

My main goals, at least for a first audio interface board, are convenient and affordable.

daperl
08-22-2013, 06:14 PM
I'm not convinced having the Teensy provide the master clock is a good idea. E.g., if you look at the WM8731 datasheet, it needs a clock with less than 1ns jitter. The K20 I2S can use an external clock - any reason not to do that?

There are quite a few DAC boards with I2S out there, what do you want to do better than them?

I would prefer to see a Bluetooth Teensy over an audio board, which is even somewhat relevant to this thread, since it could drive Bluetooth speakers.

I agree, I'm running a WM8737 ADC as master with a 12.288MHz external oscillator and it's working correctly. When I try to run the ADC as slave using the teensy 3 I2S0_MCLK I can't get the timing right.

Ben
08-22-2013, 08:00 PM
I agree, I'm running a WM8737 ADC as master with a 12.288MHz external oscillator and it's working correctly. When I try to run the ADC as slave using the teensy 3 I2S0_MCLK I can't get the timing right.
Do you have a scope to see what's wrong or different with the teensy-generated MCLK?
However, even if that particular issue will be solvable, I'd like to see the quality of T3s MCLK. Paul, I *think* I can provide you with measurements of the clock if you provide me with code for the T3. I have to check if I'm still capable of operating the measurement circuit though...

daperl
08-22-2013, 08:52 PM
Do you have a scope to see what's wrong or different with the teensy-generated MCLK?

Oh man, you are a genius. I was thinking that the MCLK couldn't be used when the teensy 3 was in slave mode. It can! It works great. No need for the external oscillator. Thank you.

I'm not sure why (maybe 'cause my teensy is running at 48MHz?), but I have to configure the MCLK with the following in order to get 12.288MHz:


I2S0_MCR = I2S_MCR_MICS(0) | I2S_MCR_MOE;
I2S0_MDR = I2S_MDR_FRACT(31) | I2S_MDR_DIVIDE(124);

PaulStoffregen
08-22-2013, 09:49 PM
I must confess, I've been targeting only 44.1 kHz sample rate, which has been working very well so far. Admittedly, "so far" is at an early stage of development...

I just did a bit more testing with the MCLK generation. It looks like setting I2S_MDR_FRACT higher than 1 (where 1 means multiply by 2) creates an utterly unusable clock waveform. The edges have very low jitter, but the waveform doesn't have consistent duty cycle. At least that's my impression by looking at it on my scope, but I haven't tried actually using a DAC or Codec with it.

Luckily, 44.1 kHz sample rate needs only I2S_MDR_FRACT(1) when using the 96 MHz PLL as input.

If you want to make some measurements, here's a test program.



void setup() {
boolean usePLL = true; // from PLL
//boolean usePLL = false; // from Crystal

SIM_SCGC6 |= SIM_SCGC6_I2S;
CORE_PIN11_CONFIG = PORT_PCR_MUX(6);
if (usePLL) {
// MCLK = 96 MHz * 2 / 17
I2S0_MCR = I2S_MCR_MICS(3) | I2S_MCR_MOE;
I2S0_MDR = I2S_MDR_FRACT(1) | I2S_MDR_DIVIDE(16);
} else {
// MCLK = 16 MHz * 12 / 17
OSC0_CR |= OSC_ERCLKEN;
I2S0_MCR = I2S_MCR_MICS(1) | I2S_MCR_MOE;
I2S0_MDR = I2S_MDR_FRACT(11) | I2S_MDR_DIVIDE(16);
}
}

void loop() {
}

PaulStoffregen
08-22-2013, 10:10 PM
Here's the jitter I'm seeing. These are delayed to the next rising edge after the one the scope is triggering, and zoomed in to the fastest time scale my scope supports. So the fuzzy area is probably 2X what we'd consider jitter, since any jitter also affects when the scope triggers.

This first one is the PLL: 96 MHz * 2 / 17

848

This second one is directly from the crystal: 16 MHz * 8 / 17.

849

You can see how the rising edges are much sharper, because there's no PLL involved.

Unfortunately, the digital divider is creating different width pulses when configured to multiply by more than 2. Even though the edges have very low jitter, the different width pulses are effectively massive jitter. I'm pretty amazed Freescale would even bother putting this hardware in their chips. I can't see how this could ever work well with pretty much any DAC or Codec?

At least I2S_MDR_FRACT(1) works very nicely, admittedly with the PLL's extra jitter, which isn't huge but is obviously not as clean as directly from a crystal oscillator.

Edit: Here's a single-shot capture of the 16 * 8 / 17 waveform. Massive changes in clock period are present, not just the 2 ns spread seen above. Totally unacceptable!!

850

pictographer
08-23-2013, 06:38 AM
My opinions/suggestions:


Leave the easy stuff to us, like soldering connectors, speakers, microphones, and controls.
Prioritize one interesting niche/use case.
Sell a kit for the number one use case.
Sell the module by itself for secondary use cases.



A few ideas for use cases:


Small battery-powered music player
Signal generator
Synthesizer for a portable musical instrument
Speech synthesizer for robotics
Signal processor for sensor applications, e.g. water flow monitoring via contact mic on water pipe
Sonar experimentation platform
Low-end radio transceiver (?), e.g. something that works in the unrestricted bands like garage door openers
802.15.4 transceiver (?)

pictographer
08-23-2013, 06:46 AM
The Adafruit module seems good as a learning toy, but not so good for making a gadget that one would use on a daily basis. The the sound quality isn't so good for music, the module itself seems larger than need be, and it's a shield for an 8-bit processor so maybe processing audio in realtime will be a bit limited.

Ben
08-23-2013, 07:53 AM
Maybe a standalone PLL-IC with a frequency ratio of 1 could help reduce the mclk jitter to an acceptable level. However I don't know if such chips exist, nor their price, nor wether they can lower the jitter far enough.

MuShoo
08-23-2013, 06:40 PM
I'll toss my two cents into the pile:

1) I'm with the other posters, no actual output *connectors* on the board - let me decide if I want to use quarter inch, 1/8th, RCA, whatever. Just give me some through-hole .1" connectors for everything.

2) I can't think of a situation that would really require a stereo input. What might be nice, though (and quite probably impossible) is to have it split into multiple boards - an output module, and an input module, with the ability to stack one/two/four/whatever input boards.

3) I'm doubtful that an on-board amp is necessary. This board should be similar to a portable CD player of old, if I need to amplify it to get it to full speaker level, I can plug it into an amp.

4) No volume knob. Keep it simple. Again, like the audio connectors, it's best to leave it up to the end user to attach a rotary encoder or a pot to the Teensy, and then use that to control the volume output of the audio board.

5) I'm really tempted to use this thing as neat little lo-fi synthesizer now. That could be really, really fun. Teensynth. (Find some old SID chips and let me make a ridiculous Commodore 64 chiptune synth, Paul! :P)

PaulStoffregen
08-23-2013, 07:28 PM
Here's what I'm planning (so far) for the first simple & low cost audio interface.

859

The pinout at the top is meant so you can use a PC front panel audio bracket. Of course, if you just want to solder wires, you can do that too.

The headphone output uses a virtual ground, which is actually about 1.5 volts, and then the 2 audio outputs to the headphones are relative to that voltage. The virtual ground must not be shorted to system ground.

This is still preliminary, so changes are possible.....

MickMad
08-23-2013, 08:30 PM
Nice stuff, Paul! I'd like to say my word, also, about some features that maybe useful to a lot of people, for sure :)
An SD card connector doesn't seem that necessary, and it also takes a lot of board space which could, although it could become useful if someone wants to implement some kind of wavetable synthesizer, so I'll keep it. Regarding some library aspects, I'd say that USB support is another important aspect to consider; I've got some basic USB audio stuff to work, but my objective is to get a board just like yours to be fully controlled via USB. Reading through the USB audio specs, I've seen that there''s a lot of things, that should be implement to make a fully working 2 in 2 out interface with digital volume control, that need to work strictly together with the I2S software; and probably, developing both aspects together might help. Or at least, the whole I2S audio library should keep some sort of backdoors to render the developing of a latter USB library faster and/or easier. I'm already doing some stuff, as I said, and I need to do it anyway :D so if you need any spare hand I'm here! :)

PaulStoffregen
08-23-2013, 08:41 PM
Integrating USB audio is something I'd like to do at some point, but definitely not until there's at least a first alpha release with basic functionality.

MickMad
08-23-2013, 08:50 PM
Cool, seems totally legit! You know, I've been developing my own ADC/DAC PCB some months ago, and I still have to build it, but the fact that hyple has done a nice I2S handler library and the fact that getting USB stuff to work the right way is a very daunting task, well, these things led me to start to work on the USB part before doing the I2S part, rest assured that developing a good working prototype is not easy nor cheap. I'm really curious about this audio library, and boards as well!

PaulStoffregen
08-23-2013, 10:17 PM
5) I'm really tempted to use this thing as neat little lo-fi synthesizer now. That could be really, really fun. Teensynth. (Find some old SID chips and let me make a ridiculous Commodore 64 chiptune synth, Paul! :P)

I believe you'll be pleasantly surprised by the synth capabilities possible using the ARM Cortex-M4 processor. ;)

Ben
08-24-2013, 12:04 AM
Having the Line I/O comply with PC audio brackets is a great idea, it saves space and does not introduce another arbitrarily defined standard. So from the board drawing I see there will be stereo line in plus a mic in and stereo line out plus headphones out. Suggestion/Question: Could the stereo line output and the Headphone output be merged? Electrically these have about the same typical voltage level (provided you use low impedance, high sensitivity phones, which is common for in ears) and only differ in the amount of current they can provide (or how low a load impedance is allowed) before distortion increases significantly.
Could you design the board area where the optional pot goes in a way that allows a rotary encoder in the same spot as an alternative? I'd prefer capacitor coupling for the headphone instead of a virtual ground, but i guess the required caps would be too large? Btw, Paul, all this is meant as constructive criticism, i'm just lacking english skills to always express myself politely :cool:

PaulStoffregen
08-24-2013, 01:05 AM
Could the stereo line output and the Headphone output be merged? Electrically these have about the same typical voltage level (provided you use low impedance, high sensitivity phones, which is common for in ears) and only differ in the amount of current they can provide (or how low a load impedance is allowed) before distortion increases significantly.


They're not the same, electrically speaking.

The line level outputs are capacitively coupled, so they can be referenced to system ground. The headphone out uses a virtual ground to avoid large capacitors. They must not be connected to another system which expect a ground-referenced AC signal.

The line level out is also probably a quieter and higher quality signal. Even though 33 ohms isn't a huge load, power amplifiers do add some noise and some distortion. This board uses a low power and low cost codec, so the signal quality certainly isn't "audiophile", but probably is comparable to the quality of a portable consumer CD or MP3 player. For people who want a cleaner signal, at least as good as this Codec can do, getting it right from the DAC before going through the headphone amp is probably a good approach.

Edit: the other reason to bring out both is based on the pretty strong consensus in the feedback so far, to make sure every signal at least comes to solder pads.



Could you design the board area where the optional pot goes in a way that allows a rotary encoder in the same spot as an alternative?


If there's a rotary encoder which fits into that small space, I could probably do this. The only rotary encoders I have are much larger.

Do you have any specific parts in mind? A link to the datasheet with mechanical drawing or recommended PCB footprint would be helpful.




I'd prefer capacitor coupling for the headphone instead of a virtual ground, but i guess the required caps would be too large?

Well, it certainly is possible All you have to do is add the capacitors in series with the 2 signals, and then you can use system ground instead of the virtual ground. Those caps aren't terribly expensive, but they do add to the board size because they're physically pretty large.

mxxx
08-24-2013, 09:59 AM
this is more of a follow-up question than a feature request, as i'm not very knowledgable about hardware capabilities and requirements - but since you've mentioned pd and max/msp in connection with the audio api, i was wondering what exactly will/will not be possible in this direction: so i assume the idea is to have a/o come up with classes analogous to "objects" such as [osc~], [phasor~] and the like, which i trust will work just fine but what about, say, objects like [tabwrite~], [delwrite~] or [susloop~] or, well, anything depending on more or less sizeable buffers. with a 16KB RAM, if i see it right, at 16bit 44.1khz stereo everything will be limited to buffer sizes << 0.1 sec, which isn't very much.

well, my question then: is writing/reading to SPI/SDcard actually fast enough to compensate? or will all that just be very tricky w/o some fast external memory, which, considering the pin count of such chips, doesn't seem to be an option? also, as i've seen people using spi rather than parallel SRAM with arduino (microchip 23LC1024), i'm guessing the usage (no fsmc) and performance of such chips can't be much superior to microSD?

john-mike
08-24-2013, 10:04 PM
This all sounds great. I'm so glad audio.h is on the way.
The only thing I might like to see is a pad directly on the line inputs to act as a AC coupled input. That way it can be used for CV or just high res pots and such.

Nantonos
08-25-2013, 04:09 AM
I must confess, I've been targeting only 44.1 kHz sample rate, which has been working very well so far. Admittedly, "so far" is at an early stage of development...

The sample rates and bit depths I have seen used in practice are:

22.05/16 or even 22.05/12 (lofi, but better than PWM)
44.1/16 (CD and rips therof, consumer audio recording)
48/24 (DAT, home studio)
88.2/x (no-one)
96/24 (home studio, pro studio)
192/24 (audiophiles with no clue)

It would be really nice to be able to do 96/24 and if not, 48/24 (just because the brickwall antialias filter has a bit more room between 20k and 24k then it does between 20k and 22.05k so can have a better behaved phase response).

Nantonos
08-25-2013, 04:10 AM
This all sounds great. I'm so glad audio.h is on the way.
The only thing I might like to see is a pad directly on the line inputs to act as a AC coupled input. That way it can be used for CV or just high res pots and such.

DC coupled?

Nantonos
08-25-2013, 04:18 AM
I believe you'll be pleasantly surprised by the synth capabilities possible using the ARM Cortex-M4 processor. ;)

I believe that lo-fi should be a "because I want to" rather than a "because its the only option, so let's pretend its cool".
A direct digital synthesis oscillator (using the audio ADC for control voltage, including audio-rate control like FM; and the DAC for audio output) is a fairly obvious application here.

john-mike
08-25-2013, 05:39 PM
DC coupled?

Hah yes of course.

PaulStoffregen
08-25-2013, 07:13 PM
so i assume the idea is to have a/o come up with classes analogous to "objects" such as [osc~], [phasor~] and the like, which i trust will work just fine but what about, say, objects like [tabwrite~], [delwrite~] or [susloop~] or, well, anything depending on more or less sizeable buffers. with a 16KB RAM, if i see it right, at 16bit 44.1khz stereo everything will be limited to buffer sizes << 0.1 sec, which isn't very much.

Yes, that's correct, the small RAM does limit this to pretty much only real-time stuff without big buffers. Limited reverb might be possible, but certainly any sort of substantial delay just isn't possible without much more memory.

The reality is a good portion of the 16K isn't really available. About 2-3K is needed for USB buffers. I might make a special "serial monitor only" USB type that uses minimal buffering, to free up memory. About 1-4K is needed for audio block buffers. The I2S output object needs 512 bytes dedicated DMA buffer memory.




well, my question then: is writing/reading to SPI/SDcard actually fast enough to compensate? or will all that just be very tricky w/o some fast external memory, which, considering the pin count of such chips, doesn't seem to be an option? also, as i've seen people using spi rather than parallel SRAM with arduino (microchip 23LC1024), i'm guessing the usage (no fsmc) and performance of such chips can't be much superior to microSD?

So far, I haven't tried writing to the SD card. The performance really depends heavily on the card, because not all SD cards are created equal. But I would be surprised if any SD card can give good simultaneous read performance while also writing.

That little 23LC1024 chip looks very interesting. Of course, it's only about 1.4 seconds of audio, but the writing process has no delay, so it should be pretty feasible to build objects like [delwrite~] using it.




It would be really nice to be able to do 90/24 and if not, 48/24 (just because the brickwall antialias filter has a bit more room between 20k and 24k then it does between 20k and 22.05k so can have a better behaved phase response).


48 kHz is looking unlikely, at least using I2S that keeps the same rate synchronous with the processor's clock, because Freescale's circuitry just can't generate a 48 kHz MCLK without massive jitter. Perhaps someone will develop an async I2S object? Hyple's library (http://forum.pjrc.com/threads/15748-Teensy3-I2S-with-DMA) has the necessary I2S code. The difficult part is "just" how to integrate it with this not-yet-published audio API stuff. Later this year or early next year, after a least few alpha or beta releases, would be the time to consider that.

On anti-alias filtering, most I2S DACs add interpolated samples, so all the aliasing is at much higher frequencies. One I have my eye on for an "audiophile interface" board is the Wolfson WM8740 (http://www.wolfsonmicro.com/products/dacs/WM8740/), which adds 8X interpolation.

The API will be designed for 16 bit samples. I'm sure the desire for 24 or more bits is going to become a frequently asked question. Maybe next year (or perhaps sooner if anyone really wants to take this on), it might be possible to build a 24 bit version and implement at least some of the objects. But there are 2 pretty big advantages to working with "only" 16 bits. First, RAM is limited. Usually anything bigger than 16 gets stored in 32 bits, which will burn up the limited RAM twice as fast. The second nice advantage of 16 bits is the Cortex-M4's DSP/SIMD instructions (which are designed for pairs of 16 bit integers packed into 32 bit words). At least initially I'm focusing on the system-level design, and in fact I'm just now starting to look into an efficient way to report CPU usage. Later I intend to work on optimizing some of the objects using SIMD instructions.

I'm sure we're going to see people regularly asking for 24 bit audio, thinking it would somehow sound better. Maybe it would? If enough people really, really want this, I'll probably work on it eventually. In the meantime, I'm probably going to adapt the I2S code to use 32 bit words (using only the first 16 bits), partly so at least the capability will be there for anyone who wants to take on 24 bits, but mostly because nearly all DACs show this in the timing diagrams.



A direct digital synthesis oscillator (using the audio ADC for control voltage, including audio-rate control like FM; and the DAC for audio output) is a fairly obvious application here.


I already have a DDS sine wave object. Will soon work on a version where each phase accumulator increment is based on the samples from another audio stream, instead of a constant.



The only thing I might like to see is a pad directly on the line inputs to act as a DC coupled input.


The ability to use the 16 bit analog input for pots or control voltages sounds pretty nice, but I'm not quite sure how it could work in the context of these Codec chips. They're really designed for only AC coupled signals.

The chip runs from a single 3.3 volt supply. Internally, it generates some DC bias voltage. That DC level probably varies with temperature and maybe other factors. You can be pretty sure the level is approximately 1.6 volts, but of course it's not really well known. For AC coupling, the specific DC bias doesn't matter. The chip just weakly couples that DC level to the input, assuming the source has infinite impedance at DC (a series capacitor), and of course the analog circuitry in the chip's sigma-delta modulator uses the same bias level.

There is a pin for filtering the chip's bias voltage. Normally you're supposed to connect a capacitor between that pin and analog ground, but nothing else. That pin may or may not be the actual DC reference for zero. It might be buffered inside the chip before weakly driving those inputs, where the buffer might add an offset voltage (which isn't an error for AC signals if the signals and the modulator inside the chip see the same voltage). Even if that pin is an accurate reference for DC zero, it's probably not a low impedance. Using it without buffering might wreck the ADC's performance.

So while I think it'd be pretty awesome to be able to use the ADC for non-audio DC coupled signals, I just don't see a realistic way for that to work well, in the context of these Codec chips designed only for audio signals. If anyone has any ideas or could point to some projects that have done this successfully, I'm certainly willing to consider it.

mxxx
08-26-2013, 11:39 AM
[...] I would be surprised if any SD card can give good simultaneous read performance while also writing.

That little 23LC1024 chip looks very interesting. Of course, it's only about 1.4 seconds of audio, but the writing process has no delay, so it should be pretty feasible to build objects like [delwrite~] using it.


thanks for clarifying. i must admit, i haven't come across anyone actually using those 23LC1024 chips in an audio type application, but if it could be done ... 1.4 seconds doesn't sound bad at all. certainly it would increase the range of possibilities. rudimentary granular synthesis also comes to mind, for example; or karplus-strong (though in some form that should be doable anyhow).

i realize it's a bit pointless without having established first that these chips actually can pull it off, but in principle it should be perfectly possible to somewhere fit another soic-8 chip on the SPI lines going to the SD card, no? either as an alternative or possibly even with it's own chip select?

mxxx
08-26-2013, 12:03 PM
ps: as to DC coupling, the openmusiclabs shield is DC-coupled on both inputs and outputs, as far as i know (well, that's what their website says). i'm not sure about the ADC end of things, but i'd figure that people in need of generating DC / subaudio signals will be better served with a voltage DAC. control voltages, for example, which is the most obvious musical application, tend to be 0-5V at least, more likely 10VPP, so one would have to come up with additional circuitry anyways.

jsfetzik
08-26-2013, 07:43 PM
Lots of good discussion, but i figured I would add my current audio desires to the list.

My use is to add sound to Sci-Fi props, such as blaster pistols and light sabers. So I need the small size to fit inside the props. Sound quality is not a big deal, because the speakers are pretty much crap anyway. :) It just needs to be heard.

One useful feature would be to loop a single track.

PaulStoffregen
08-26-2013, 07:47 PM
I'll try to squeeze a place to add a 23LC1024 onto the bottom right corner of the board.

I saw the Open Music Labs claim "you can even use it as a high quality ADC and DAC for signals of all kinds". They also promote their shield as capable of 24 bits. While those statement aren't necessarily false, I believe it's safe to say they do not really genuinely the product's capability. I suppose every organization or company needs to decide what they consider acceptable for marketing their products. Those claims are pretty far beyond what I'd publish.

Dan
08-27-2013, 12:22 PM
This is a good idea !
My wishes :

AKM or cirrus logic converters are used in pro audio cards.

CD quality is minimal (stereo outs 44.1Khz 16 bits), and is enough for me.

I want to create a synth. polyphonic wavetable synth if possible. with low latency. You press a midi key of the piano. you hear the sound with near 0 latency.
Maybe I can dream of DSP like reverb ...

One Line Out stereo jack is good. so you can plug any speakers. with built in jack, or 3 holes.

For me, Audio Input is not needed, because you need a mic preamp, and good quality mic preamp is another story.

Built in amp is not needed.

I don't need volume knob. Just let the volume at max by default, and we can lower it by software.

Regards,

Dan

stefanovic
08-27-2013, 05:54 PM
Integrating USB audio is something I'd like to do at some point, but definitely not until there's at least a first alpha release with basic functionality.

Acknowledged.

Still, it would be nice in the future to build a DIY teensy-based usb audio card with multiple inputs (if it's ever possible considering the needed processing power/throughput, I am not knowledgeable enough to assess this), with open source drivers that would work on any platform...

Best wishes for this audio project!

Ben
08-27-2013, 08:43 PM
So when this SRAM IC will be used as a buffer, will the accompanying audio library depend on that chip (in other words: will everyone who wants to use the audio library have to attach this IC to the T3) ? I wouldn't consider this a bad thing, just curious.


If there's a rotary encoder which fits into that small space, I could probably do this. The only rotary encoders I have are much larger.
Do you have any specific parts in mind? A link to the datasheet with mechanical drawing or recommended PCB footprint would be helpful.
I tried to find a small rotary encoder, but I really could not find anything sufficiently small to fit in the space a small pot would occupy. :(

PaulStoffregen
08-27-2013, 08:53 PM
Still, it would be nice in the future to build a DIY teensy-based usb audio card with multiple inputs (if it's ever possible considering the needed processing power/throughput, I am not knowledgeable enough to assess this), with open source drivers that would work on any platform...


Teensy3 is certainly capable of moving pretty substantial amounts of data around. Moving 44 kHz 16 bit stereo uses in a few percent of the CPU time.

Today, the USB code doesn't really support isync transfers. The code is all there if you want to try hacking, but the USB stuff is quite complex. I'll work on it eventually, but many other things are much higher priority.

PaulStoffregen
08-27-2013, 08:58 PM
So when this SRAM IC will be used as a buffer, will the accompanying audio library depend on that chip


Only certain objects (if any) would depend on that chip.



(in other words: will everyone who wants to use the audio library have to attach this IC to the T3) ? I wouldn't consider this a bad thing, just curious.


All the other stuff will work without that specific chip.

In fact, whether anything ever gets written for that chip still remains to be seen. But if it does, it'll only be specific objects than need a deep buffer. Most likely it would be a delay object, or perhaps reverb simulating a very large room.

MickMad
08-27-2013, 09:49 PM
it would be nice in the future to build a DIY teensy-based usb audio card


Teensy3 is certainly capable of moving pretty substantial amounts of data around. Moving 44 kHz 16 bit stereo uses in a few percent of the CPU time.

Today, the USB code doesn't really support isync transfers. The code is all there if you want to try hacking, but the USB stuff is quite complex.

I'm already working on that; in fact, I'm finishing a design based on the WM8740 and the WM8786, with a pair of PGA4311 for volume control, and an input selector with ADG333As analog switches, that activates an LME49724 which converts the unbalanced signal of a guitar to a balanced one, to correctly drive the ADC; there's also a DC-DC converter that converts the USB 5 V to +/- 5 V to correctly drive all of the analog subcircuits. I'm also already working on the USB library stuff, but as Paul said, that stuff is really complex; right now, I've managed to let the Teensy enumerate as a USB compliant microphone, and it also streams some data, although not as it should be; there's a topic I opened for that, if anyone needs more in-depth information.

PaulStoffregen
08-27-2013, 11:59 PM
I added 5 knobs and 2 buttons to my prototype. So far, I'm only controlling the main volume and the frequency of a DDS sine wave. Will do more soon.

871

mxxx
08-28-2013, 05:43 AM
Only certain objects (if any) would depend on that chip.



All the other stuff will work without that specific chip.

In fact, whether anything ever gets written for that chip still remains to be seen. But if it does, it'll only be specific objects than need a deep buffer. Most likely it would be a delay object, or perhaps reverb simulating a very large room.

oh sure, that wouldn't make a great deal of sense, ie making anything dependent on an (as yet) untested chip. btw, i'd be curious to know if anyone knows of any alternatives (low pin count ones, i mean). i only brought it up as RAM seemed to be one critical resource/thing that was missing in my messing around with teensy 3 audio so far; not audio quality or processing speed. (i've made my own wm8731 board a while back as i need a lot of buffering circuitry -5/5V -> 0-3V and v.v.) for example, i have no problems running 4 linearly interpolated lookuptable oscillators plus some other not particularly optimized stuff in the DMA callback, but already going down to low frequencies with a basic karplus strong sketch i've tried proved a bit tricky, and that's monophonic. delay more generally is an obvious example, but so is most audio processing that is to take place between input and output, or on whatever is stored on your SD card .. other than bitcrushing.

MickMad
08-28-2013, 02:41 PM
48 kHz is looking unlikely, at least using I2S that keeps the same rate synchronous with the processor's clock, because Freescale's circuitry just can't generate a 48 kHz MCLK without massive jitter. Perhaps someone will develop an async I2S object?


Paul, have you considered the idea of using an external clock source for MCLK? The Cirrus Logic CS2000 looks like a very good solution, and it requires a maximum of 7 external components. It is also very small, in a 10 MSOP package.

czak
08-28-2013, 02:47 PM
I'm currently working on a guitar sound recording/processing project (in a form of a stompbox (https://en.wikipedia.org/wiki/Effects_unit)), so my priorities for an audio module would be:

(please excuse newbie parlance)

- input & output suited for electric guitar (solder pads; suitable gain level for ADC; controllable gain perhaps)
- mono, CD quality
- easy access to storage; recording & playback sampled sound to uSD seems perfect

...actually if I had these 3 features, my project would be ready :)

stefanovic
08-28-2013, 03:00 PM
I'm already working on that; in fact, I'm finishing a design based on the WM8740 and the WM8786, with a pair of PGA4311 for volume control, and an input selector with ADG333As analog switches, that activates an LME49724 which converts the unbalanced signal of a guitar to a balanced one, to correctly drive the ADC; there's also a DC-DC converter that converts the USB 5 V to +/- 5 V to correctly drive all of the analog subcircuits. I'm also already working on the USB library stuff, but as Paul said, that stuff is really complex; right now, I've managed to let the Teensy enumerate as a USB compliant microphone, and it also streams some data, although not as it should be; there's a topic I opened for that, if anyone needs more in-depth information.


@Paul: unfortunately, I do not think I have enough time and knowledge right now to handle such a project, especially if you consider it complex. I know this can be quite disappointing to see people contribute to requests and not contribute to code, but it's the sad truth, not enough time...

@MickMad: I checked the thread, thanks for working on this, and good luck, I'm sure this will eventually spark _much_ interest inside the digital audio community. I do not know it this can be of any help, but the LUFA driver includes _some_ code related to usb audio e.g. https://github.com/abcminiuser/lufa/tree/master/Demos/Device/ClassDriver/AudioInput (MIT License for non-commercial)

Nantonos
08-28-2013, 04:49 PM
48 kHz is looking unlikely, at least using I2S that keeps the same rate synchronous with the processor's clock, because Freescale's circuitry just can't generate a 48 kHz MCLK without massive jitter. Perhaps someone will develop an async I2S object? Hyple's library (http://forum.pjrc.com/threads/15748-Teensy3-I2S-with-DMA) has the necessary I2S code. The difficult part is "just" how to integrate it with this not-yet-published audio API stuff. Later this year or early next year, after a least few alpha or beta releases, would be the time to consider that.
Fair enough. (Sorry for the delay in responding, I was flying back from the US to France)


On anti-alias filtering, most I2S DACs add interpolated samples, so all the aliasing is at much higher frequencies. One I have my eye on for an "audiophile interface" board is the Wolfson WM8740 (http://www.wolfsonmicro.com/products/dacs/WM8740/), which adds 8X interpolation.
Good point about the anliasing being shifted up by interpolation, I had forgotten about that.
I have seen (but not played with) an audiophile board using the WM8741, the Opus (http://www.twistedpearaudio.com/digital/opus.aspx).


The API will be designed for 16 bit samples. I'm sure the desire for 24 or more bits is going to become a frequently asked question. ...

I'm sure we're going to see people regularly asking for 24 bit audio, thinking it would somehow sound better. Maybe it would? If enough people really, really want this, I'll probably work on it eventually. In the meantime, I'm probably going to adapt the I2S code to use 32 bit words (using only the first 16 bits), partly so at least the capability will be there for anyone who wants to take on 24 bits, but mostly because nearly all DACs show this in the timing diagrams.

The only realistic use cases for 24bits are for recording, where 16bits is problematic as an input format for headroom and noise reasons, and the next convenient stage up from that is 24. Much of the hardware is of course only delivering 18 or 20 ENOB (or 16 if you get some really bad 24bit hardware). I record at 48/24 or 96/24. I see the benefit there.

Once all the equalisation and gainstaging is done, the mixed down (and mastered, if you believe in that sort of thing) result is fine at 16bits.

About the "sounding better" argument: I have an audio interface (Presonus AudioBox 44VSL) which handles 4 channels of input and output at 96/24, a good headphone amp (Lake People G109, using balanced connection to the AudioBox) and fairly accurate headphones often used for mixing (Audio Technica ATH M50S). I also have a selection of music (FLAC, lossless) at higher bitrates and sample depths, mostly from Linn Records, up to 96/24. With that equipment I am unable to hear any difference at all between 96/24 and 96/16 or indeed 48/24 or 48/16. Maybe someone with better equipment or better ears can reliably tell them apart.


I already have a DDS sine wave object. Will soon work on a version where each phase accumulator increment is based on the samples from another audio stream, instead of a constant.
That would be good. I know its conventional for a DDS sinewave to have tables for only one quadrant and to use the same tables for the other three; for non-sine uses its usefull to have the option of a full cycle table however.



The ability to use the 16 bit analog input for pots or control voltages sounds pretty nice, but I'm not quite sure how it could work in the context of these Codec chips. They're really designed for only AC coupled signals.
Also a fair point. CV sampling needs DC coupling, obviously. But it can also change at up to audio rates (say 8kHz or so) so the sampling can need to run at audio-like rates.

MickMad
08-28-2013, 05:35 PM
I'm currently working on a guitar sound recording/processing project (in a form of a stompbox (https://en.wikipedia.org/wiki/Effects_unit)), so my priorities for an audio module would be:

(please excuse newbie parlance)

- input & output suited for electric guitar (solder pads; suitable gain level for ADC; controllable gain perhaps)
- mono, CD quality
- easy access to storage; recording & playback sampled sound to uSD seems perfect

...actually if I had these 3 features, my project would be ready :)

For the input part, you need a good opamp and some external components, like resistors for gain setting and capacitors to bypass the power supply noise, and if you want it to work very well a dual supply is needed for the opamp, also; considering the fact that this kind of circuitry is really not needed for everyone, and that it will obviously eat some space on the board itself, it seems difficult that such things will get on the board, because Paul then should eventually add an option to bypass such circuitry, which will need even more space on the board... so, I don't think this will ever make its way to the final product.

BUT, it is very easy to accomplish such a thing by making a little external board that amplifies the guitar level (~300 mV RMS) to the line level of the ADC (1 or 2 V RMS usually, in low power ADCs), with the said components, and then you could easily solder its output to the line level input pads of the audio board.

For the output part, I assume that you would like to plug this stompbox directly into a guitar amplifier; remember that a guitar amplifier expects a guitar level, so you should do the opposite thing as the input, that is lowering the line out of the board ( again, 1 or 2 V rms) to guitar level. Again, this kind of stuff is really not needed in a design which is pursuing the "one size fits all" rule, so it is quite difficult it will get on the final board, the easiest and fastest thing is to DIY and add it to the final board.

PaulStoffregen
08-28-2013, 05:37 PM
External MCLK was discussed earlier. TL;DR = The software needs the same rate sync'd to the CPU clock. At least the first version will not support async I2S relative to the CPU clock.

I haven't tried recording to SD yet. Bill did some optimization work on SdFat several months ago to improve write speeds, at least with better quality cards. I'm optimistic recording will be possible, but I'm less hopefully that you'll be able to continuously record and simultaneously play another file from elsewhere on the same card simultaneously.

Eventually I'll work on USB audio. The main difficulty is everything that exists in usb_dev.c is based on 64 byte USB packet buffers. To usefully support isync, a second set of buffer management will be needed for the isync endpoints that stream faster than 64 kbytes/sec.

USB audio support will also require syncing the USB clocked data to the CPU clock. That's the same problem (or very similar) as the external MCLK issue.

Years ago I looked at LUFA's audio examples. In fact, I reported a bug to Dean which resulted in dramatically improved audio output (he still decimates without proper filtering, but 48 -> 32 causes far less aliasing than 48 -> 16), or as Dean put it "ultrasonic whine".

Of course, LUFA uses polled register I/O because it targets 8 bit AVR. On Teensy3, the USB works using DMA and interrupts, without any hardware support for the simple but inefficient I/O method on AVR, so other than the descriptors (which are published in LOTs of places), there's very little in LUFA that applies to Teensy3. The specific issue of managing larger DMA buffers doesn't even exist on LUFA, since the AVR hardware only provides access to the USB buffers as a 1-byte-at-a-time FIFO implemented completely in hardware.

Dean and I also have almost completely opposite coding styles. Dean prefers extensive type definitions and macros in headers that leverage compiler syntax, which is nice in that it results in very verbose and descriptive code, but it also creates a massive number of lines of code and a tremendous amount of "stuff" to learn to simply use it. The descriptions are based on whatever's in those headers, so volumes of extensive documentation are needed. In theory everything is so well abstracted that you only need LUFA's documentation. He organizes things using many files in even directory hierarchy. I prefer a minimalistic style, using mostly primitive types (uint8_t, uint32_t, etc) with structs/typedefs used only where really compelling (eg: my USB descriptors are just arrays of bytes), and with relatively few macros and special names defined, even if that means putting the direct hardware register names right into the code. My goal is usually to put all the code for something into just 2 files, one C or CPP for the code and one header for definitions other code needs to use it. My idea of "readable" code is short enough to fit in 2 side-by-side windows, so I can read most of it without much scrolling. Dean's idea of readable is much more verbose. I just took a quick look... Dean's latest LUFA has a total of 568 header files (1322 files total) nested in 6 levels of subdirectory hierarchy, with 243 headers in the library proper hierarchy, and of course all the code in about twice that many code files. Admittedly, LUFA supports much more hardware and features many more options, but still, it's a very verbose style that I find pretty difficult to digest. Even just reading Dean's USB descriptors requires finding numerous headers to see what all the definitions really do.

MickMad
08-28-2013, 06:56 PM
The main difficulty is everything that exists in usb_dev.c is based on 64 byte USB packet buffers. To usefully support isync, a second set of buffer management will be needed for the isync endpoints that stream faster than 64 kbytes/sec.

USB audio support will also require syncing the USB clocked data to the CPU clock. That's the same problem (or very similar) as the external MCLK issue.

Oh, that's why I can't get the right data to be written on the isochronous endpoint needed to stream audio through USB... well, maybe I'll try to modify usb_dev.c to support different kinds of buffers, you know, those 64 bytes are also very harsh to work with when dealing with 16-24 bits audio :D if you have any suggestion about these kinds of hacks, tell me on the usb audio specific topic, this stuff can get kinda off topic for this one.

MuShoo
08-29-2013, 08:40 AM
I'll just chime in to say that, having not used LUFA ever, that coding style sounds like a nightmare to parse and get acclimated to. Whereas all the Teensy related 'low level' (ie, USB descriptors, etc) is pretty easily navigated and quickly understood.

TL;DR: I like your coding chops, Paul.

JarkkoL
09-05-2013, 02:14 AM
I would just like something where I can efficiently push audio data (8/16 bits, mono/stereo, this should be something you can choose based on your application) to a double buffer on the audio device and that raises interrupt when the end of buffer is reached during playback, so I can hook interrupt to fill more data. Basically what SB16 did back in the days. I would keep all the other crap (USB, SD card, etc.) off from the device and focus doing one thing well, which is audio playback. If you really want, you could maybe add equalizer on the device.

PaulStoffregen
09-05-2013, 12:18 PM
I've been thinking recently about the things people will want to actually do with Teensy3 audio.

So far, I've come up with 5 categories.


Play audio: pre-recorded music, sound effects. Data is read from media and played without modification.
Play musical notes or synthesize sounds, using wavetables, FM, other synth algorithms? Usually at least a pitch/note# and intensity/velocity specify how the note will be played. Most of these applications probably want polyphonic support.
Analyze real-time audio: music visualization, beat/rhythm detection, audio user interfaces, others?
Modify real-time audio: guitar effects peddles, voice effects
Record audio


Have I missed any important applications?

A first software release isn't going to do everything, but I'm trying to look forward to future applications and at least design the APIs in ways that will enable important uses. The last thing I want to do is publish a 1.0 (or 0.1) library and then later have to make incompatible API changes after people are already using it.

mxxx
09-05-2013, 01:46 PM
I've been thinking recently about the things people will want to actually do with Teensy3 audio.

So far, I've come up with 5 categories.


Play audio: pre-recorded music, sound effects. Data is read from media and played without modification.
Play musical notes or synthesize sounds, using wavetables, FM, other synth algorithms? Usually at least a pitch/note# and intensity/velocity specify how the note will be played. Most of these applications probably want polyphonic support.
Analyze real-time audio: music visualization, beat/rhythm detection, audio user interfaces, others?
Modify real-time audio: guitar effects peddles, voice effects
Record audio


Have I missed any important applications?

A first software release isn't going to do everything, but I'm trying to look forward to future applications and at least design the APIs in ways that will enable important uses. The last thing I want to do is publish a 1.0 (or 0.1) library and then later have to make incompatible API changes after people are already using it.

makes sense to me. especially items 2,3, and 4. as to all things synthesis, perhaps it'll be nice though to keep any midi-or osc type controls/envelope stuff separate from the actual synthesis algorithms. though you can always disentangle things later of course..

JarkkoL
09-05-2013, 04:46 PM
Unless if you are planning to provide true wavetable support with bunch of memory to load all the samples in, forget #2. I would also advice against Adlib kind of playback support. In fact, all of these playback features you mentioned can be achieved with the simple double buffer with interrupts. Don't fall into DirectX Retained Mode trap that no one is going to use because it sucks. If you want to provide interface with higher level functionality, then provide OPTIONAL additional library for it, and keep the low-level immediate interface that communicates with the device clean from the higher level functionality.

I implemented a music player for Arduino and what's time intensive is A) mixing the samples and B) pushing the data to the DAC with an interrupt. However, you can't provide A without good wavetable support. Having wavetable support with at least 1MB of memory would be nice though, but it complicates your design quite a bit I'm sure. Think of mixing ~32 16-bit samples @ 44KHz with panning support and the way you expose this in the API. Then you need volume, pitch & pan control for all the channels and the way to set interrupts which is triggered at given position for each channel to deal with looping (forward/backward/ping-pong). And if you want to get more complex, think of adding ogg-vorbis decoding support (since mp3 is patented).

Here's a music player I did for Arduino and was thinking of porting it to Teensy. The quality isn't great because on Arduino there's only 32kb of memory for all the audio data (samples, music patterns) & the code, and the DAC I have is horrible resistor DAC. If there was more memory in form of a wavetable, mixing was done off chip and there was proper DAC, the quality would be much better.

http://www.youtube.com/watch?v=b_QbBE_fXZs

mxxx
09-05-2013, 05:48 PM
Unless if you are planning to provide true wavetable support with bunch of memory to load all the samples in, forget #2.

http://www.youtube.com/watch?v=b_QbBE_fXZs

huh, why's that? think Max Matthews rather than Wolfgang Palm? anyways, granted memory will be a limiting factor, as was pointed out by paul above. still, things look better as with AVRs, no? in terms of audio (file) playback, catering to various formats such as ogg vorbis and so on doesn't strike me as particularly interesting, musically speaking. real time resampling capabilities etc would.

JarkkoL
09-05-2013, 06:22 PM
huh, why's that?
If there's no proper wavetable support what you think you can achieve? Recreating awful Adlib-like device, huh? I want to release uC from doing time consuming audio sample mixing & decoding, thus you need to be able to load custom sample data to the device (potentially MBs of it). OGG decoding is interesting because I don't want to spend time on uC for that, and I don't need various formats, OGG is just fine. I WAS talking about resampling AND mixing those samples AND beyond to have truly useful audio device.

PaulStoffregen
09-05-2013, 07:54 PM
What exactly is meant by "proper wavetable support"?

Realistically, 32 note polyphony probably isn't going to be possible using software on a Cortex-M chip. Four might be do-able, maybe even 6 or 8 as the code gets optimized with the M4's SIMD instructions?

Regarding wavetables, so far I've been looking at the SoundFont file format. Are wavetable synthesis sounds commonly distributed in other formats?

Also, on the latest PCB prototype, I added unpopulated placed to solder chips. There's a place to add a 23LC1024 which might be useful for delays up to about 1.5 seconds, and another place to solder a AT45DB161E flash memory (2 megabytes) for wavetable storage. How useful these will really be in practice remains to be seen....

JarkkoL
09-05-2013, 09:18 PM
What exactly is meant by "proper wavetable support"?
From the top of my head, you should have:
1) enough memory to make the wavetable useful (or at least make it something I can expand myself if it's too expensive off-the-shelf, this is what GUS had back in the days where you could buy extra memory for the card)
2) support for different sample formats (both 8/16-bit PCM is fine, no need for example ADPCM and alike for now, though it's nice of course!)
3) each audio channel should have volume, frequency & pan control for mixing
4) forward/backward/ping-pong looping for each channel
Once I have that, I can control each channel's state to play music, which isn't very performance consuming.
Then you can of course have special stuff, like equalizer/channel, global volume control, etc. but above I would say is the minimum feature set. I don't know how you plan to load samples to the wavetable though.


Realistically, 32 note polyphony probably isn't going to be possible using software on a Cortex-M chip.
Hmh, isn't this ~200MHz 32-bit chip? I'm currently mixing 12 8-bit mono channels at 37KHz on 16MHz/8-bit Arduino, so surely you could do much much better than that! I don't support panning though and only 8-bit samples, so adding panning/16-bit adds some extra cost. Also not sure how fast reading from an external flash is and if you are able to supply enough data for mixing. I guess that's where your bottleneck will be.


Regarding wavetables, so far I've been looking at the SoundFont file format. Are wavetable synthesis sounds commonly distributed in other formats?
I'm playing MOD, S3M, IT & XM formats, which contain music patterns (i.e. notes & effects) and samples. The samples are usually 8/16-bit PCM (signed or unsigned), though IT format has specific compression format, but I just decompress it to PCM. Some formats support also ADPCM and OGG, but I don't care about those as I have never seen mod file using those compression formats. These mod files use 4-32 audio channels. The various effects (e.g. vibrato, arpeggio, portamento, etc.) do not really need anything special from audio device but they are implemented simply by adjusting pitch/volume of each channel.

If you are interested, you can get mod files for example from The Mod Archive (http://modarchive.org/index.php?request=view_top_favourites) and use OpenMPT (http://openmpt.org/) for playback and investigation of samples/patterns.

Edit: Oh and you should also definitely have linear interpolation in resampling. Adds some extra cost to the mixing routine though.

PaulStoffregen
09-05-2013, 09:58 PM
Is there good documentation available somewhere for the .xm or .it file formats? I did some searching and found a lot of history of old MOD software, even Amiga stuff. The closest I found to file format "documentation" was a couple open source mod players.

JarkkoL
09-05-2013, 11:06 PM
For IT I used this spec (http://schismtracker.org/wiki/ITTECH.TXT) for parsing the format. It doesn't describe the compressed sample parsing though, so I used this spec (http://wiki.multimedia.cx/index.php?title=Impulse_Tracker) and also here (http://schismtracker.org/hg/annotate/8887bc3a9178/fmt/compression.c) is some code for decompressing compressed samples. For XM format parsing I used this spec (ftp://ftp.modland.com/pub/documents/format_documentation/FastTracker%202%20v2.04%20%28.xm%29.html) and also this (ftp://ftp.heanet.ie/disk1/sourceforge/u/project/uf/ufmod/XM%20file%20format%20specification/FastTracker%20II,%20ADPCM%20XM%20and%20Stripped%20 XM/XM_file_format.pdf.gz).

mxxx
09-06-2013, 06:04 AM
If there's no proper wavetable support what you think you can achieve? Recreating awful Adlib-like device, huh?

easy, ... i was only curious as to why you were so dismissive. you wrote "forget #2", so i was under the impression you were talking about wavetable synthesis, which is a slightly ambiguous term, but obviously you were not. in the direction of #2, i'm pretty sure you can do things other than recreating adlib devices.

that said, i'm still not convinced that "OGG decoding is interesting" in terms of an API. mp3 and aftermath are formats made for transmitting, consuming and selling (or stealing) music, not making it.

anyways, if you want to build a tracker, that's fine with me. i would have thought that's an application though, rather than part of some API.

JarkkoL
09-06-2013, 02:55 PM
that said, i'm still not convinced that "OGG decoding is interesting" in terms of an API. mp3 and aftermath are formats made for transmitting, consuming and selling (or stealing) music, not making it.
Ok, so you are not convinced that playing music on an audio device is interesting :rolleyes:


anyways, if you want to build a tracker, that's fine with me. i would have thought that's an application though, rather than part of some API.
It's not an API specific to mod playback/tracker, but generic interface for handling audio sample mixing. With practical use-cases you can map what's the generic feature set required for the API.

Nantonos
09-06-2013, 05:37 PM
I've been thinking recently about the things people will want to actually do with Teensy3 audio.

Play audio: pre-recorded music, sound effects. Data is read from media and played without modification.
Play musical notes or synthesize sounds, using wavetables, FM, other synth algorithms? Usually at least a pitch/note# and intensity/velocity specify how the note will be played. Most of these applications probably want polyphonic support.
Analyze real-time audio: music visualization, beat/rhythm detection, audio user interfaces, others?
Modify real-time audio: guitar effects peddles, voice effects
Record audio



If I could abstract that to a block diagram

WRITE WRITE
^ ^
| |
IN >--+--> PROCESS >--+--> OUT
| |
^ ^
READ READ

then your cases are


Play audio: READ -> OUT
Play musical notes or synthesize sounds READ -> PROCESS -> OUT
Analyze real-time audio: IN -> PROCESS -> WRITE
Modify real-time audio: IN -> PROCESS -> OUT
Record audio: IN -> WRITE


I would debade whether "most" of the synthesize sounds cases would need polyphony. Some would, some would not. The 'play musical notes' (chiptunes, MIDI to General MIDI audio) would mostly be polyphonic, agreed. But those would probably not need separate polyphonic outs, just a stereo or mono mixdown.

One block flow that is missing from your list is READ -> PROCESS -> WRITE which I guess could be labelled non-realtime audio modification. Or it could be argued that at least one of IN or OUT must be present for it to qualify as audio (it depends on what the facilities are in the processing block and if people want to use that for non-realtime as well).

Oh, modify audio could also be IN+READ -> PROCESS -> OUT (either reading instructions for modification, or outputting audio based on computation on two audio streams (like ring modulation). Depends on whether this is seen as a mono circuit or a stereo circuit or a mono channel where you can add multiple channels (that would affect the processing part as the modules would need to communicate which makes things harder, though also more powerful as you are adding processing nodes?).

Dan
09-07-2013, 09:12 PM
SoundFonts + Midifile + General MIDI are 3 things I am using.... Polyphony and reverb too... But maybe I am asking too much :)

JarkkoL
09-08-2013, 02:23 PM
What kind of features SoundFont has that require special features from an audio device with wavetable support?

Dan
09-08-2013, 02:42 PM
a soundfont file includes many things.
All the WAV files. loop points, instruments mapping and tunning, and many more...
The fact is that you can find many SF2 files in internet.
This will help to not have to Create your own wavetable format and use existing soundbanks, and not have to create yours.

JarkkoL
09-08-2013, 02:50 PM
Yeah, I'm totally for supporting existing formats, but just wondering what kind of features it has that require HW support (essentially special support from the mixing routine)

Dan
09-08-2013, 02:56 PM
I don't understand your question... I don't know what can't be done by software and need hardware.
The synth can play and MIX together 32/64/128 wav files, with a low latency and send them to the audio out hardware.
Also there is some settings that vary with the time.
For example, loop a wav file of a piano note, then, play it for 10 seconds, decreasing the volume every time, following volume envelopes.
Also the same for pitch or filters envelopes.

JarkkoL
09-08-2013, 03:16 PM
Volume/pitch/pan envelopes are more of a software features. I see HW doing the heavy lifting and software controlling it for various effects. This keeps HW simplier and more general purpose. So I think it's better to extract HW features from the format and implement support for various formats in software. Thinking of it, might be good to look into XAudio or OpenAL interface to get an idea what kind of features you should have in HW

Dan
09-08-2013, 03:37 PM
The hardware need fast access to memory where the wav/soundfonts files are.
Maybe adding external memory 32MB/64/128/256 ...

JarkkoL
09-08-2013, 04:02 PM
Might be also good to add support for negative volumes to enable implementation of Dolby Surround. Also doing FFT on the master buffer would be nice support for visualization etc.

PaulStoffregen
09-08-2013, 07:55 PM
I've been looking at the SoundFont 2.04 spec. It's quite complex. There is still much I need to digest, but it seems the core function is playing sampled clips at variable rates, where the latter part of the clip can loop. A delay-attack-hold-decay-sustain-release envelope, resonant lowpass filter, tremolo, vibrato, chorus and reverb effects can be applied and the parameters for all those effects can vary. There also seems to be some sort of layering capability, involving multiple clips playing and mixing together, but I do not yet understand that part of the SoundFont format.

I found numerous dead links while searching. Here's a copy of the Soundfont spec I found after much searching.....
903

PaulStoffregen
09-08-2013, 08:17 PM
Yeah, I'm totally for supporting existing formats, but just wondering what kind of features it has that require HW support (essentially special support from the mixing routine)

Obviously it's possible to do entirely in software, because FluidSynth (http://sourceforge.net/apps/trac/fluidsynth/) can, at least using a powerful processor. How well a Teensy3 with only a 96 MHz Cortex-M can do it remains to be seen.....

PaulStoffregen
09-08-2013, 08:25 PM
... good to add support for negative volumes to enable implementation of Dolby Surround.

Can you post a link to any technical documentation about these algorithms?

Please keep in mind this needs to be public domain, create commons or otherwise free to use. PJRC certainly does not have the ability to license proprietary Dolby technology, and even if we could, my intention is to publish the entire audio library as open source.

PaulStoffregen
09-08-2013, 08:59 PM
Here's what the audio shield will probably look like....

906 905

http://oshpark.com/shared_projects/2k03eMcK

PaulStoffregen
09-08-2013, 09:06 PM
The optional "MEM" chip on bottom side is meant to be a W25Q64 (http://www.winbond.com/hq/enu/ProductAndSales/ProductLines/FlashMemory/SerialFlash/W25Q64FV.htm) or W25Q128 (http://www.winbond.com/hq/enu/ProductAndSales/ProductLines/FlashMemory/SerialFlash/W25Q128FV.htm) flash memory, for storing short sound clips or (maybe) wavetables.

JarkkoL
09-09-2013, 12:12 AM
I don't have documentation, but what you do is play the sample you play in left channel negated on right channel to make it appear in the surround channel. So you need ability to do 180 degree phase shift, i.e. multiply the sample with negative volume.

JarkkoL
09-09-2013, 12:27 AM
Obviously it's possible to do entirely in software, because FluidSynth (http://sourceforge.net/apps/trac/fluidsynth/) can, at least using a powerful processor. How well a Teensy3 with only a 96 MHz Cortex-M can do it remains to be seen.....
You need some support in your device if you are going to support wavetables though. If you plan to provide only master buffer access and have essentially a simple DAC with a buffer, then you have to do everything in SW on host controller. Supporting wavetables makes it more complex but obviously more efficient for the host. Supporting envelopes and various effects require update of the audio channels in pretty low frequency (e.g. 50Hz, like in mods) and doesn't put much stress on the host controller, so you may want to consider keeping that part in SW instead to simplify the audio device and keep it more generic, maybe.

JarkkoL
09-09-2013, 12:41 AM
The optional "MEM" chip on bottom side is meant to be a W25Q64 (http://www.winbond.com/hq/enu/ProductAndSales/ProductLines/FlashMemory/SerialFlash/W25Q64FV.htm) or W25Q128 (http://www.winbond.com/hq/enu/ProductAndSales/ProductLines/FlashMemory/SerialFlash/W25Q128FV.htm) flash memory, for storing short sound clips or (maybe) wavetables.
Is this memory able to provide ~5.4MB/s random access (4 bytes / read)? That's what's required for 32 channel 16-bit stereo mixing at 44.1KHz. From datasheet I saw it's able to do 50MB/s continuous but didn't see random access performance.

Edit: Actually double that if you do linear interpolation, so 10.8MB/s (8 bytes / read)

Nantonos
09-09-2013, 01:04 AM
The optional "MEM" chip on bottom side is meant to be a W25Q64 (http://www.winbond.com/hq/enu/ProductAndSales/ProductLines/FlashMemory/SerialFlash/W25Q64FV.htm) or W25Q128 (http://www.winbond.com/hq/enu/ProductAndSales/ProductLines/FlashMemory/SerialFlash/W25Q128FV.htm) flash memory, for storing short sound clips or (maybe) wavetables.

Nice. 128Mbits is 8M 16-bit samples which allows multiple wavetables (to select multiple waveforms, for mixing, or per-octave tables for bandlimited synthesis - see for example http://www.musicdsp.org/files/bandlimited.pdf‎)

PaulStoffregen
09-09-2013, 01:07 AM
The W25Q128 is capable of pretty high speeds, but the SPI port on Teensy3 is limited to 24 Mbit/sec, so 3 Mbyte/sec is the absolute maximum possible speed. Each random access incurs an overhead of 4 bytes, but then may read any number of sequential bytes at the full speed.

I have some ideas for software and buffering and conversion to an intermediate format that (hopefully) may help make the most of the hardware. But soundfonts that make heavy use of the extra/optional features like the parameterized resonant filter, vibrato, and reverb are going to chew up CPU time. Even with the SIMD optimizations (which certainly aren't going to be used in early releases), there's only so much of that CPU intensive processing a microcontroller can do.

JarkkoL
09-09-2013, 01:26 AM
Ok, but I thought you want to do mixing on the audio microcontroller, not on Teensy, or did I miss something? That's the point of wavetables after all, not to stress host microcontroller.

Nantonos
09-09-2013, 01:33 AM
Hmh, isn't this ~200MHz 32-bit chip?
96MHz.


I'm currently mixing 12 8-bit mono channels at 37KHz on 16MHz/8-bit Arduino, so surely you could do much much better than that!
Assuming for the moment that performance scales linearly with clock speed and independent of architecture (which it doesn't) you have 12 channels of 8 bit mono on a 16MHz chip and are asking for 32 channels of 16 bit stereo which is 32/12 * 2 * 2 * 16 = 170 MHz. Teensy 3.0 is a 48 MHz chip clocked to 96 MHz.

If you really need 32 channel stereo polyphony with significant processing on each channel then a platform like Beaglebone (http://beagleboard.org/Products/BeagleBone) (720MHz ARM Cortex-A8, 256Mb DDR2) or BeagleBone Black (http://beagleboard.org/Products/BeagleBone+Black) (1GHz ARM Cortex-A8, 512Mb DDR3, floating-point accelerator) would seem more appropriate.

Nantonos
09-09-2013, 01:41 AM
Ok, but I thought you want to do mixing on the audio microcontroller, not on Teensy, or did I miss something? That's the point of wavetables after all, not to stress host microcontroller.
What audio microcontroller? The Wolfson Audio Codec WM8731 is an I2S DAC and ADC, not a microcontroller.

JarkkoL
09-09-2013, 01:48 AM
Well duh, I thought the plan was to have microcontroller on the audio shield doing all the mixing!

PaulStoffregen
09-09-2013, 05:24 AM
The shield has only the codec chip. The codec is likely to be SGTL5000. All the processing and mixing happens in the MK20 microcontroller chip on Teensy3.

I've been working with the WS731 chip and the SGTL5000, and of course starting a library over the last few weeks. The ARM Cortex-M is indeed much faster than an 8 bit AVR on normal Arduino, but there are limits. I'm pretty sure the MK20 could easily read 32 arrays from flash, sum them together and feed that to the I2S output. But 32 soundfonts making heavy use of the CPU-intensive extra features is another matter. At this early stage (no actual code written to do all that stuff), I don't anyone could really estimate accurately how many simultaneous voices can be played.

The hardware and audio library isn't ready for release yet, but it will be within a matter of weeks. The Teensy3 of course is available now, so is Hyple's I2S library (http://forum.pjrc.com/threads/15748-Teensy3-I2S-with-DMA), so if anyone wants to fiddle with code to implement wavetables and investigate what is (or might be) possible in more detail, they certainly can.

I'd also be curious to know how FluidSynth performs on a Beaglebone or Raspberry Pi, if anyone can find that info or give it a try?

mxxx
09-09-2013, 09:26 AM
I'd also be curious to know how FluidSynth performs on a Beaglebone or Raspberry Pi, if anyone can find that info or give it a try?

not sure about fluidsynth, but there's plenty of people using pd or supercollider with these boards of course. i haven't seen any performance comparisons or analyses, would be curious too. ccrma satellite doesn't even include fluidsynth by default, it seems; only supercollider, pd, faust and chuck, which i guess makes a lot of sense when you think about the user community presumably targeted by ccrma (well, and that being more interesting software from a diy perspective). in my own experience with rpi/pd, one can easily run a lot of osc~ objects (20+) but haven't tried to max things out. a guy from the local art school, who use BBB for supercollider stuff, tells me BBB performance is better.

i'm not sure though whether those linux boards are the best reference points. in the same ballpark, preenFM comes to mind for instance (maple mini), which i think can handle 6 or 8 notes polyphony. but there's as much to be said about focusing on one voice that sounds good, rather than many voices that sound bad. also of course, one voice can get CPU intensive enough in its own terms. the less toy like things i have seen tend to be monophonic. the mutable instruments "braids" for instance contains a stm32f4, i believe, sounds pretty decent (i haven't seen the code but apparently it can do all sorts of things, bandlimited wavetable; FM synthesis; some physical modelling stuff etc). there's similar things which are dsPIC33 based, all sounding nice.

looks as if that W25Q128 is the same footprint as the 23LC1024, so i figure it will be possible to try these out, too. nice.

PaulStoffregen
09-09-2013, 10:01 AM
looks as if that W25Q128 is the same footprint as the 23LC1024, so i figure it will be possible to try these out, too. nice.

Yes. In fact, I made a special SOIC-8 footprint that (hopefully) can accept the wider W25Q128 or the narrow 23LC1024.



in the same ballpark, preenFM comes to mind for instance (maple mini), which i think can handle 6 or 8 notes polyphony. but there's as much to be said about focusing on one voice that sounds good, rather than many voices that sound bad.


My thoughts exactly. Well, except I'm really shooting for at least 4 note poly, and of course more if I can. :)

Then again, FM (or at least phase modulated) is extremely easy. I already wrote a modulated oscillator, but haven't tested it much yet. I've been focusing mostly on the I/O objects, library API, and hardware for a first release. In fact, a first release will likely only support a W25Q128 chip for audio clip playing, so I can test the hardware before PJRC sells the boards. More advanced software support, like soundfont-based wavetables, can come later.

mxxx
09-09-2013, 11:43 AM
Yes. In fact, I made a special SOIC-8 footprint that (hopefully) can accept the wider W25Q128 or the narrow 23LC1024.

i see, will be curious to try it out.


Well, except I'm really shooting for at least 4 note poly, and of course more if I can. :)

Then again, FM (or at least phase modulated) is extremely easy. I already wrote a modulated oscillator, but haven't tested it much yet. I've been focusing mostly on the I/O objects, library API, and hardware for a first release. In fact, a first release will likely only support a W25Q128 chip for audio clip playing, so I can test the hardware before PJRC sells the boards. More advanced software support, like soundfont-based wavetables, can come later.

for basic NCO based stuff, that should be perfectly possible, i would have thought. i don't have the tools to run any systematic performance measures, but using hpyles DMA i2s library, i have experienced no problem whatsoever (as a coding non-expert == inefficient code) running 4 slightly detuned instances of an oscillator (which is basically 4 calls to arm_linear_interp_q15 per sample plus mixing it all together; i'm not using envelopes, these come from somewhere else), i haven't tried to push it though and still need to implement bandlimited wavetables, which will roughly double the processing going on.

JarkkoL
09-09-2013, 04:11 PM
I'm planning to port my mod player to Teensy 3.0 so that will give you some reference performance numbers at least. I optimized the mixing and interrupt routines in AVR asm, but there's also equivalent C++ versions which are roughly half the performance, so it should be fairly straightforward to do the first port to Teensy and then work on Cortex asm optimized version. I just need to figure out how to setup timer interrupt to run at given frequency on Teensy. I had a quick look at Cortex-M4 instruction set, and since it's 32-bit and runs 3x faster than my Uno, I would expect it to be able to handle 32 channels at 44KHz @ 48MHz, even with stereo panning and linear interpolation. I' not familiar with Cortex SIMD instruction set either, but if it's anything like SSE on PC, that should give nice additional boost to increase the number of channels even further. I'm currently adding support for volume envelopes, but after that could move on the Teensy port.

PaulStoffregen
09-09-2013, 06:19 PM
I'm planning to port my mod player to Teensy 3.0 so that will give you some reference performance numbers at least.

Great. I'm really curious to hear it. :)




I just need to figure out how to setup timer interrupt to run at given frequency on Teensy.


Use IntervalTimer (http://forum.pjrc.com/threads/14-Teensy-3-0-and-interrupts?p=30822&viewfull=1#post30822). Just create an IntervalTimer object, then call the begin(function, period_microseconds) to schedule your code to run. You can use a float for the microseconds. If it's a constant, it's converted at compile time to the integer actually used by the hardware.

The upcoming audio library will process data in 128 sample blocks, which is approx 2.9 ms at 44.1 kHz. If you start coding now, I'd highly recommend generating 128 sample blocks and plan on 44.1 kHz sample rate, which should make using the library relatively easy.

JarkkoL
09-09-2013, 06:42 PM
Thanks, I'll have a look at IntervalTimer.

Both buffer size and mixing frequency are something I can easily configure. The buffer is double buffered actually, so that while the interrupt is playing one half of the buffer the mixer routine is filling the other half. If you are interested, I'm actually planning to release the code under BSD-3 License.

PaulStoffregen
09-09-2013, 06:46 PM
Great. I'll look forward to seeing it when you're ready.

With the DMA-based library, there's very little interrupt overhead for transmitting the buffer. An interrupt is triggered every 64 samples, but it only runs for several microseconds, so the total CPU time to stream the data out is just a couple percent.

JarkkoL
09-12-2013, 01:51 AM
I got the XM/IT volume envelope support implemented and ported the player to Teensy (no asm optimized yet though), but the audio quality on Teensy is pretty poor compared to Arduino. Is it possible that the output voltage of pins isn't constant depending on which pins are on/off, thus making resistor DAC behave poorly? Or there's some bug in the code.

Edit: After some testing, it seems that this is indeed a problem with Teensy that zero-pins behave as sinks with some resistance and mess up the resistor DAC. I guess this should be fixable with diodes?

PaulStoffregen
09-12-2013, 06:14 AM
Are you sure it's really a hardware problem?

I did some testing with PWM driving lower value resistors high and low, to measure the on-resistance of the mosfets inside the chip. I got about 20 ohms between the pin and 3.3V for logic high, and about 15 ohms between the pin and ground for logic low. That's not perfectly symmetrical.

Could you post schematic or photo of the wiring, a small test program that just drives from 0 to 255 (or whatever the max is) in a loop?

JarkkoL
09-12-2013, 04:22 PM
Yes, I'm sure. I have the DAC connected to Teensy pins 0-7 (PORTD). If I only connect pin 0 and keep flipping bit 0 (other bits are 0) in PORTD at 20KHz, I hear high frequency sound (10KHz). Now if I connect pin 1 in Teensy to the DAC (the code is same and pin 1 is still low) I can clearly hear that the sound gets attenuated (this doesn't happen on Arduino).

I don't have schematic, but pin 0-7 are connected to 10467Ohm, 5194Ohm, 2597Ohm, 1304Ohm, 650Ohm, 326Ohm, 163Ohm, 81Ohm resistors respectively (i.e. about power-of-two resistances). Output of the resistors is connected to potentiometer, whose output is connected to speaker. And speaker ground is connected to Teensy GND (next to pin 0).

So when pin 1 is low, my guess is that some electricity goes from pin 0 through the 10467Ohm resistor BUT then back through 5194Ohm resistor to the ground when pin 1 is low /: If I put diode between pin 1 and the 5194Ohm resistor, the attenuation doesn't happen. I don't have enough diodes to properly test if this fixes the problem though.

Ps. I don't want to hijack this thread, so if you want, feel free to move these posts to some other thread.

PaulStoffregen
09-12-2013, 07:43 PM
Yes, I'm sure. I have the DAC connected to Teensy pins 0-7 (PORTD). If I only connect pin 0 and keep flipping bit 0 (other bits are 0) in PORTD at 20KHz, I hear high frequency sound (10KHz). Now if I connect pin 1 in Teensy to the DAC (the code is same and pin 1 is still low) I can clearly hear that the sound gets attenuated (this doesn't happen on Arduino).


Without seeing the code, it's hard to know what's going on here.

But one thing that's different between Teensy3 and Arduino is the default state of the pins. After a reset, every pin on Teensy3 is disabled. They only become enabled after calling pinMode.

Another thing to consider is PORTD is emulated in software. When you write to the PORTD register, on Teensy3 there is no AVR register. Instead, some software in avr_emulation.h emulates that register by writing to the 8 pins. They're not all updated at precisely the same moment.

JarkkoL
09-12-2013, 08:48 PM
Before starting the playback I set the pins for PORTD like this:
DDRD=0xff;
and the timer interrupt is just:


static bool s_val=false;
s_val=!s_val;
PORTD=s_val?0x01:0x00;


Another thing to consider is PORTD is emulated in software. When you write to the PORTD register, on Teensy3 there is no AVR register. Instead, some software in avr_emulation.h emulates that register by writing to the 8 pins. They're not all updated at precisely the same moment.
Ah, that's good to know. So I should use GPIOX_PSOR registers instead?

PaulStoffregen
09-12-2013, 08:58 PM
If you'd like me to look into this, please start a new thread, with a (hopefully small) complete program and any other info needed to reproduce the problem.

When I can reproduce a problem here, I can do something about it. Otherwise, all I can do it guess and post general info.

wanorris
09-16-2013, 05:44 AM
I've been looking at the SoundFont 2.04 spec. It's quite complex. There is still much I need to digest, but it seems the core function is playing sampled clips at variable rates, where the latter part of the clip can loop. A delay-attack-hold-decay-sustain-release envelope, resonant lowpass filter, tremolo, vibrato, chorus and reverb effects can be applied and the parameters for all those effects can vary. There also seems to be some sort of layering capability, involving multiple clips playing and mixing together, but I do not yet understand that part of the SoundFont format.

I found numerous dead links while searching. Here's a copy of the Soundfont spec I found after much searching.....
903

Hi, I just stumbled across this, and I think what you're making here looks terrific.

I didn't see that anyone had responded to the bolded part yet, and I have some familiarity with SoundFonts, so I thought I'd offer some help in case you still need it. The basic idea is that some instruments cannot be reproduced effectively as a single sample being pitch scaled. One obvious example would be the human voice and formants -- ideally you don't want the formants to scale the same way as the pitch of the note. So by layering multiple samples with different playback characteristics, you get more control over this. Or, for example, you might be making a snare drum patch that has a combination of a noise and a pitched oscillator, and want to do different things with each -- give them different envelopes, different velocity scaling, etc. And at the extreme end, you could simply be designing fancy multitimbral synthesizer patches where each note is intentionally made up of several different layered sounds.

Overall, the Teensy and a board like this seems like it might be a great tool for making a DIY synth, or possibly even a groovebox. I don't actually have a Teensy yet, but I definitely plan to get one, and this board should be perfect for the kind of stuff I'm interested in.

CheapB
09-24-2013, 12:31 AM
My opinions/suggestions:


A few ideas for use cases:


Small battery-powered music player
Signal generator
Synthesizer for a portable musical instrument
Speech synthesizer for robotics
Signal processor for sensor applications, e.g. water flow monitoring via contact mic on water pipe
Sonar experimentation platform
Low-end radio transceiver (?), e.g. something that works in the unrestricted bands like garage door openers
802.15.4 transceiver (?)


I would like to add a few items to the list:
- Haptic technology - "rumble" and other effects for home theater and games
- guitar effects

Xeon
09-24-2013, 11:30 AM
Sonar experimentation platform.
Very important for my updated version of cora.

CoraB might use about 5 teensy boards.

Derangedgamer123
09-25-2013, 03:33 PM
Personally I feel it would be great to be able to implement most of these DSP algorithms from this free ebook on DSP.

http://www.dspguide.com/pdfbook.htm

I love this book BTW :-)

Actually I think I will make this another post......

mxxx
10-02-2013, 08:15 AM
paul - would you be willing to leak some details of your wavetable/DDS implementation? - i've been poking around for software capable of editing/generating arbitrary waveforms recently, which is a very convenient thing to have in this connection, and was wondering what kind of format you were aiming at, mostly as i'd like to keep things compatible as far as possible with whatever you come up with (knowing it's going to be far more decent) ? single cycle / integer arrays? or something more intricate? existing editors seem to be geared towards this or that wavetable synthesizer, with formats that tend not to be overly memory efficient; there's only a few exporting single cycles and i found none generating band-limited single cycle sequences, which i guess would be the ideal scenario here. myself i've been playing around with a scheme that generates the band-limited single cycles during set up (16x256 integer arrays), writing them into the SD card and loads them when needed, but there's probably smarter ways of achieving that, say, preparing the wavetables in advance and just writing them into the flash.

Derangedgamer123
10-02-2013, 02:21 PM
Is this the same as setting up a LUT for the given wave?(F(x))*

PaulStoffregen
10-02-2013, 05:13 PM
would you be willing to leak some details of your wavetable/DDS implementation?

Normally I wouldn't release any code early, and honestly this probably isn't useful without the rest of the library, but here's my DDS sine wave implementation.

It's really pretty simple, just a 32 bit phase accumulator (phase and phase_increment are uint32_t, not float, even though it's assigned from a converted float) where the upper 8 bits index into a sine lookup table, and the next lower 16 bit are used to linear interpolate between 2 table entries. The lowest 8 bits aren't used, other than accumulating phase. Those low 8 bit might never have anything useful, since the increment is converted from a float with only 23+1 bit mantissa. Maybe later I'll consider an improved conversion from float to uint32 that properly maps the original mantissa to all 32 bits, but that's a relatively minor issue.



void AudioSineWave::frequency(float f)
{
if (f > AUDIO_SAMPLE_RATE_EXACT / 2 || f < 0.0) return;
phase_increment = (f / AUDIO_SAMPLE_RATE_EXACT) * 4294967296.0f;
}

void AudioSineWave::update(void)
{
audio_block_t *block;
uint32_t i, ph, inc, index, scale;
int32_t val1, val2;

//Serial.println("AudioSineWave::update");
block = allocate();
if (block) {
ph = phase;
inc = phase_increment;
for (i=0; i < AUDIO_BLOCK_SAMPLES; i++) {
index = ph >> 24;
val1 = sine_table[index];
val2 = sine_table[index+1];
scale = (ph >> 8) & 0xFFFF;
val2 *= scale;
val1 *= 0xFFFF - scale;
block->data[i] = (val1 + val2) >> 16;
//Serial.print(block->data[i]);
//Serial.print(", ");
//if ((i % 12) == 11) Serial.println();
ph += inc;
}
//Serial.println();
phase = ph;
transmit(block);
release(block);
return;
}
phase += phase_increment * AUDIO_BLOCK_SAMPLES;
}


Edit: also, at some point, I'll probably try to optimize this code using the SIMD instructions. That might require doubling the lookup table size, so each pair of values is 32 bit aligned? I have measured this non-optimized code using about 3% of the CPU time, running at the default 44.1 kHz sample rate.

This could pretty easily be turned into any arbitrary waveform by replacing the sine lookup table with whatever waveform you want. I'm planning to do something like that for the library....



but there's probably smarter ways of achieving that, say, preparing the wavetables in advance and just writing them into the flash.

Yes, I've actually thought quite a bit about converting soundfont to an intermediate format. So far, only ideas, not any real code.

I've been focusing on efficient I/O, the library base class that provides all the infrastructure, and a ton of mundane things needed to actually get the hardware released. Currently I'm working on the test strategy and bed-of-nails test system...

mlu
10-02-2013, 05:28 PM
you might save one multiplication by doing something like:

block->data[i] = val1 + (scale*(val2-val1) >> 16);

The 0xFFFF-scale subtraction is traded for val2-val1.

PaulStoffregen
10-02-2013, 05:43 PM
Thanks. Later (probably much later) I'm going to work on optimizations. I'll certainly look into this.

But this sort of optimization involves a lot of studying the actual generated assembly. All multiplies in this chip are single cycle. There's even a SIMD instruction that does two 16x16 multiplies and adds then to the same accumulator, all in a single cycle. There are also double fetch instructions, that fetch 32 bits using a single bus cycle, but populate two registers which each 16 bit half. I'm pretty excited about the optimization possibilities. I've done a LOT of assembly language for microcontrollers over the last 20 years, but never before with such an amazing chip with SIMD instructions.

It's tempting to fiddle with optimizations now, but that would only delay releasing with perfectly good if not optimally fast code.

mxxx
10-02-2013, 07:02 PM
Normally I wouldn't release any code early, and honestly this probably isn't useful without the rest of the library, but here's my DDS sine wave implementation.
[...]
Yes, I've actually thought quite a bit about converting soundfont to an intermediate format. So far, only ideas, not any real code.

thanks -- that's much more than i wanted to know actually. but good to know, 8 bit then.

as to soundfont, never had to do with it i must say. a quick look at the specifications tells me this might be very much about "preset" sounds? i couldn't find anything relating to wavetables except soundfont provides a wavetable oscillator, but maybe i was looking at the wrong document. anyways, thanks again!

PaulStoffregen
10-02-2013, 07:33 PM
Here is the soundfont specification I'm reading.

http://forum.pjrc.com/attachment.php?attachmentid=903&d=1378670117

From chapter 6, starting on page 20:



The smpl sub-chunk, if present, contains one or more "samples" of digital audio information in the form of linearly coded
sixteen bit, signed, little endian (least significant byte first) words.


Also, about the looping of the sample data:



Within each sample, one or more loop point pairs may exist. The locations of these points are defined within the pdta-list chunk, but the sample data points themselves must comply with certain practices in order for the loop to be compatible across multiple platforms.

The loops are defined by "equivalent points" in the sample. This means that there are two sample data points which are logically equivalent, and a loop occurs when these points are spliced atop one another. In concept, the loop end point is never actually played during looping; instead the loop start point follows the point just prior to the loop end point. Because of the bandlimited nature of digital audio sampling, an artifact free loop will exhibit virtually identical data surrounding the equivalent points.

In actuality, because of the various interpolation algorithms used by wavetable synthesizers, the data surrounding both the loop start and end points may affect the sound of the loop. Hence both the loop start and end points must be surrounded by continuous audio data. For example, even if the sound is programmed to continue to loop throughout the decay, sample data points must be provided beyond the loop end point. This data will typically be identical to the data at the start of the loop. A minimum of eight valid data points are required to be present before the loop start and after the loop end.

The eight data points (four on each side) surrounding the two equivalent loop points should also be forced to be identical. By forcing the data to be identical, all interpolation algorithms are guaranteed to properly reproduce an artifact-free loop.


It is true that most of the verbiage throughout the spec is about a lot of features for "presets", which seems to be a variety of ways to associate samples and parameters for the resonant filter, reverb and other effects to ranges of notes and velocity values. There's also a LOT of stuff about modulators and other forward-looking features that apparently aren't used in any actual soundfonts.

I must confess, I still haven't actually implemented any of this yet, so everything i know so far is only based on reading through this spec a couple times.

mxxx
10-03-2013, 07:47 AM
ah ok, googling around a bit i can see better what this is doing now (i was looking at the wrong places first - there's only 5 hits for soundfont on puredata.hurleur etc vs a LOT of them on sites where people discuss VST plugins and the like). it would no doubt be a powerful feature, for sampling applications and such, if that would be supported out of the box, albeit a quite high level one, more application than api.

the wavetable "format" i had in mind was the one nantonos had mentioned a few posts back, which more directly pertains to the core DDS. for example, if you look at the mutable instruments algorithms, the latest of which are done for a cortex M4/fixed point as well, the wavetables tend to be 16 (or 17) single cycle 8bit waveforms, each covering a certain frequency range; here's another example, same idea, http://www.earlevel.com/main/2012/05/25/a-wavetable-oscillator%E2%80%94the-code/ where the wavetables are implemented as a struct. it's not such a big deal, of course, and something i/we/the users can come up with themselves, should they see the need.

emueyes
10-23-2013, 09:44 AM
For some time I've been looking at building a good quality digital audio system. My conclusions have led to a design using a board running Linux, and an audio board for USB to S/PDIF conversion. A lot of the USB boards also offer I2S. And there are a lot of them, for example at http://hifiduino.wordpress.com/2013/04/03/c-media-cm6631a-based-usb-i2s-interface/#comment-12246

In my scenario, the Linux board acts as front end, running XBMC for it its utter ubiquity. Basically a pretty interface to the filesystem, and of passing them to the sound stage. I'd agree, connectors take up a lot of space, and unfortunatley there seem to be a lot of physical standards. Maybe a block of pins to allow the use to choose what headers are used? An external coax connector can carry many channels, breakout into channels can be made in an amp. Also, the board will quite possibly be used in a chassis, with other boards, where physical headers are a liability.

The are two issues that remain in constant discussion. Correct clocking and hence reduction of jitter, and quality of the power supply. An (optional) $100 power supply is not uncommon. Talk of clocks would span volumes. I don't assume to understand the fine points of either of these issues, but the fact is that people spend a lot of time and effort in making them work correctly. Allowing people to choose their own DAC is a benefit, same with PSUs. Make it modular; perhaps have an effects board, or a MIDI board. People can then use them or not.

My use case may be different; I only want this for stereo music. The surround audio from video goes directly to the decoder in my receiver. So, my need is for a more direct signal path,

What a great opportunity! Customers in the design loop :)

glt
10-24-2013, 08:58 PM
My main application would be digital output (I2S) of uncompressed/lossless audio files stored in an SD card and support for the different families of audio frequencies.
Also external audio frequency clock input (two clocks for the 44.1K and the 48K families) in order to avoid complex derivation of audio frequencies as to minimize jitter

emueyes
10-25-2013, 12:35 PM
I had just looked back at some previous ideas. I think a SATA port would be great, if not that then a USB port for storage. With over 200GB of music files a SATA drive would be the preferred method of storage. Then like I said, the board could be quite simple in function: read files from SATA drive, output them to S/PDIF or I2S. No mixing, DSP, volume - all that should be done by later stages.

MickMad
10-25-2013, 05:20 PM
I had just looked back at some previous ideas. I think a SATA port would be great, if not that then a USB port for storage. With over 200GB of music files a SATA drive would be the preferred method of storage. Then like I said, the board could be quite simple in function: read files from SATA drive, output them to S/PDIF or I2S. No mixing, DSP, volume - all that should be done by later stages.

I really don't think a SATA port is something worthy and useful in an audio application such as this. In fact, it could easily become useless for like 99.9% of the buyers that will use this audio board. I mean, if you buy an audio board, you would expect it to have audio-specific functions, not storage-specific functions. An SD card slot already takes so much space on a board like this, and could easily become useless to most of the buyers; I can't imagine for a SATA port.

PaulStoffregen
10-25-2013, 09:34 PM
I believe we're several years away from microcontrollers having SATA capability. For now, SDHC is pretty much the available media.

glt
10-28-2013, 02:41 PM
Is the discussion here also about the audio libraries? For playing files out of SD card to I2S (and taking the master clock externally) there is no need for a separate board.

MickMad
10-29-2013, 01:08 AM
Is the discussion here also about the audio libraries? For playing files out of SD card to I2S (and taking the master clock externally) there is no need for a separate board.

There IS need for an external board to do such things, as you obviously need, to say the least:

1)An SD card slot to be attached to the Teensy;
2)An I2S-compatible chip, such as the WM8731 codec from Wolson that will probably be on the board Paul is working on.
2bis)Theorically, the master clock for the Teensy and for an I2S device could be taken from a dedicated chip.

Needless to say that both of this come in SMD-only packages, and an I2S chip in particular may necessitate some passive external components. Unless you want to solder jumper wires from those tiny SMD pads to a breadboard, which is fine if you have the ability and the patiency to do such work, an external board is the only way to go.

mhelin
11-03-2013, 09:18 AM
Here's what the audio shield will probably look like....

906 905

http://oshpark.com/shared_projects/2k03eMcK

That's a tiny board, maybe too tiny after all. Anyway, for adding memory also consider MRAM of FRAM nv SPI RAM's, might be already fitting the layout.
Everspin MR20H40 is the MRAM variant with 512kx8 (512 kbytes) chip which could be used as RAM or EEPROM or whatever, so for you could implement for example digital delay or reverb, or store few seconds of audio (depending on sample rate). Add another chip and double the RAM.
http://www.everspin.com/PDF/EST_MR2xH40_prod.pdf
http://de.mouser.com/ProductDetail/Everspin-Technologies/MR25H40CDC/?qs=sGAEpiMZZMsSm7LhMeloEPcGBwqnPuOP



Considering the bad quality of the generated MCLK then maybe it would be best to use a DAC with a PLL and a MCLK output. That is CS4350 by Cirrus which can sync to LRCLK input only, and can be used with simple passive single-ended output filter:
http://www.cirrus.com/en/products/cs4350.html
http://de.mouser.com/Search/ProductDetail.aspx?qs=bUPhaerQQeHZRk%252buErHRaQ==

Now you need extra ADC chip, there is the PCM1803A from TI which offers >100 dB SNR and is easy to use (no need for input buffer opamps either though guess all A/D's should be driven from low impedance source anyway):
http://de.mouser.com/Search/ProductDetail.aspx?qs=bUPhaerQQeHZRk%252buErHRaQ==
http://www.ti.com/lit/ds/sles142a/sles142a.pdf

Obviously those parts will cost more that a single cheap CODEC but then you would get much better SQ.



http://www.everspin.com/PDF/EST_MR2xH40_prod.pdf

PaulStoffregen
11-03-2013, 10:17 AM
Everspin MR20H40 is the MRAM variant with 512kx8 (512 kbytes)


I just looked it up and saw $15 for small quantity and $11 in volume!! Is that right?

Looks like the "small flag" part could be soldered onto the pads I put on the bottom side of the PCB.




Obviously those parts will cost more that a single cheap CODEC but then you would get much better SQ.


The first board is definitely going to be use the SGTL5000 codec. Its ADC is only in the 80 dB SNR & -70 db THD+N range. I've spent quite a bit of time listening to it. If you feed input to output with a lot of gain, of course you can amplify that tiny noise. But it really is very small when set at a gain reasonable for any real input signals.

The DAC also isn't going to win any audiophile awards (100 dB SNR and -80 dB THD+N), but it does sound as good as any portable CD player. The noise is very small.


Maybe sometime next year I'll make an "audiophile" board. Or maybe someone else will do it? There are a LOT of these high-end ADC and DAC chips on the market. Once the library is published, the really tough software side will be done (other than making MCLK an input).

mxxx
11-04-2013, 12:55 PM
I just looked it up and saw $15 for small quantity and $11 in volume!! Is that right?

Looks like the "small flag" part could be soldered onto the pads I put on the bottom side of the PCB.




looks interesting. but i guess these would have to be reflowed?

emueyes
11-05-2013, 12:45 PM
There seems to have been a considerable amount of work in progress

http://forum.pjrc.com/threads/15748-Teensy3-I2S-with-DMA

http://hifiduino.wordpress.com/2012/09/12/teensy-3-0-with-i2s-interface/

Taking advantage of the I2S interface could possibly lead to some very high quality audio and using what is there already. That holds great potential I reckon, I2S to a suitable DAC would be great :)

PaulStoffregen
11-05-2013, 02:04 PM
Just a quick update....

PCBs have been ordered, so the audio shield design is finalized and we're moving into production of the first batch.

Recently I've been working with the audio input side. I added a 256 point FFT object, so there's now something more interesting to actually do with the input audio, rather than just routing it to the output. Yesterday I put together a simple spectrum analyzer example (it'll be in the library's examples) which displays on a normal character LCD using the LiquidCrystal library.

I've been debating setting up a Kickstarter or Indiegogo campaign, to share info and let people sign up early for shields from the first batch. What do you think? Should I do it?

nlecaude
11-05-2013, 03:34 PM
Why not ! I'd be glad to be an early adopter, I have a project where I need to light up pianos using ws2811 strips. I'm doing it on a Raspberry pi now with PureData but using the audio shield with FFT would probably reduce costs/complexity a lot !

Nantonos
11-05-2013, 04:20 PM
I've been debating setting up a Kickstarter or Indiegogo campaign, to share info and let people sign up early for shields from the first batch. What do you think? Should I do it?

Yes, firstly for promotion or dissemination purposes and also to get payment in advance rather than having to front a large purchase and wait until they all sell.
Bear in mind that kickstarter seems to frown on the "muliples of a product" rewards unless they form part of an obvious set. But groups of items are fine (T3+audio, T3+audio+LCD, T3+audio+LCD+fancy wooden box with your name in lights and VIP status, etc. Or "5.1 surround bundle" with a T3 and three audio to get six channels, etc).

Extra examples or extra library additions can be stretch goals (the APNG library which I backed did that).

Derangedgamer123
11-07-2013, 02:34 PM
Im game!!!

mhelin
11-08-2013, 12:29 PM
Maybe sometime next year I'll make an "audiophile" board. Or maybe someone else will do it? There are a LOT of these high-end ADC and DAC chips on the market. Once the library is published, the really tough software side will be done (other than making MCLK an input).

There are plenty of DAC's and ADC's but without a proper MCLK output or an external PLL it's not worth using them anyway. Also there are a little bit better codecs like AK4556 which might also be reasonable choice for CODEC. Teensy 3.0's Cortex-M4 chip also supports multichannel audio output (DSP/TDM format) so a DAC like PCM1691 should work fine there for applications like digital crossover for multiway speakers.

Regarding MCLK input can't you just sync to external LRCLK and/or SCLK (BCLK) clocks? MCLK (sometimes called System Clock or SCK) is not part of the core I2S interface specification, it's a signal that's needed only for the oversampling 1-bit (or "few" bit) converters. Teensy controller shoudn't need that for anything. For the best quality clock (less jitter) you should have external clock and use a single ADC or DAC which can be used in master mode to generate the other clocks.

PaulStoffregen
11-08-2013, 12:47 PM
Teensy3 creates a pretty good MCLK for 44.1 kHz.

recri
11-12-2013, 11:45 PM
I am a bit late to the party, but let me say this will work for my applications.

It should be fine for most audio applications just as it is. And thanks for figuring out that the I2S/PLL only works for 44.1 kHz. It might have been very painful designing to use the PLL at other sample rates and discovering belatedly that it didn't do other sample rates. Masterpiece of engineering, that, a PLL which can be programmed for thousands of possible frequencies, but only works correctly at one. This is sort of what you expect from the consumer audio market.

And this will work for my software designed radio (SDR) application, too. Faster sample rates and more bits per sample are useful in a radio because they translate to wider bandwidth and greater dynamic range, but anything is better than nothing.

When you get to trying the audiophile board, there's a lot of accumulated design experience in the sdr-widget and audio-widget google groups which built usb sound cards using the Atmel AT32UC3A3 targeting the best possible performance. The SDR version is full duplex, 48/96/192kHz, 24b/s, stereo using an AD5394A ADC and a CS4344 DAC. The Audio version has used a variety of DACs and power supplies and oscillators in a quest for something most of us cannot hear. The higher sample rates require a USB 2.0 audio driver (UAC2) on the host side, something Microsoft has not yet bothered to do, so they only work on Linux and MacOS. (There may be a work-around for this, there was certainly a lot of effort to make one.) And note that there are several ADCs that appear to be as good as the AK5394A until you look at the noise spectrum at high sample rates.

-- rec --

mxxx
11-13-2013, 01:48 PM
Teensy3 creates a pretty good MCLK for 44.1 kHz.

mmh, .. so is the consensus to go with 44.1kHz, if one wanted to keep things compatible with the audio API? i'm getting a bit confused as to the MCLK issue, or how serious it is - earlier in this thread, at least one person reported success when deriving a 12.880 MHz clock from the teensy3 (things "working correctly") but ever since MCLK-from-teensy3 was getting a great deal of bad press. i'm asking as for my next little board i'd like to swap the WM8731, which i've been using so far, for a CS4344; and, if possible, run it in double speed mode/96kHz, in which case i'd have to go with something like I2S0_MDR = I2S_MDR_FRACT(15) | I2S_MDR_DIVIDE(124); -- which doesn't seem to be a good idea, given Paul's measurements a few pages back ("utterly unusable clock waveform")? i guess i could always revert to 44.1, just wondering...

PaulStoffregen
11-13-2013, 03:13 PM
That's correct. For MCLK output from Teensy3, use only 44.1 kHz, or 22.05, or 11.025. If you set I2S_MDR_FRACT to anything other than 0 or 1, the MCLK output is terrible.

Sometime next year, after a couple revs of the audio library have filled in more functionality (eg, I've put in a lot more programming time), I'll probably work on MCLK as input, and perhaps an "audiophile" board, and maybe even 24 bit extensions in the library?

One problem with MCLK as an input to Teensy3 is the data stream is no longer synchronous to Teensy3's own clock. The audio library lets you also use an analog input pin as a source, and PWM pins as output. Without the clocks phase locked, mixing those on-chip interfaces with externally clocked I2S will force the streams to resync, which is not done very gracefully. But I believe it should be possible to make a modified copy of the I2S object with external MCLK that works well, as long as you don't also use CPU clocked I/O in the same program. I'm going to work on adding more audio effects and other nice features before looking into that. But maybe after the initial release, someone else will tackle it?

mxxx
11-13-2013, 04:52 PM
That's correct. For MCLK output from Teensy3, use only 44.1 kHz, or 22.05, or 11.025. If you set I2S_MDR_FRACT to anything other than 0 or 1, the MCLK output is terrible.

okay, i see. thanks for clarifying. so perhaps i'll stick to 44.1kHz for the time being but make provisions for adding an external oscillator, just in case. personally, i'm not so much craving for "audiophile" hardware specs (as in crazy decoupling schemes etc), only was hoping to add some dynamic range in my (synthesis) application. (truth is, an experienced DSP person could get way better sounds out of an 8bit DAC than i could get out of $$ hardware, so generally i tend to be more worried about the software side of things)

Derangedgamer123
11-25-2013, 03:08 PM
I hope this project is coming along :-) !!!

PaulStoffregen
11-25-2013, 03:26 PM
Yes, it is. I've been pretty quiet on this... but work is progressing on all those little mundane details to release a new hardware product.

Derangedgamer123
12-13-2013, 04:20 PM
Yes, it is. I've been pretty quiet on this... but work is progressing on all those little mundane details to release a new hardware product.

With Teensy 3.1 it almost seems that an external board isn't needed anymore!

MichaelMeissner
12-13-2013, 05:05 PM
With Teensy 3.1 it almost seems that an external board isn't needed anymore!
Given the Teensy 3.1 only has one DAC (digital to analog) pin, I would imagine you would still want an external board to do stereo (plus it is probably convenient to have an external board for things like voltage protection, 3.5mm connectors, etc.)

Nantonos
12-13-2013, 06:03 PM
Plus the built in DAC is 12bits and likely doesn't update at audio rates with a solid clock.

PaulStoffregen
12-13-2013, 06:10 PM
So far, the only code I've written for the DAC is analogWrite(). But I do plan to support the DAC in the audio library, perhaps not on the first release, but soon...

The DAC can trigger from the PDB, which of course is how I'll support it in the audio library, so it should stream 44.1 kHz sampled audio. The datasheet says the full-scale settling time is 15 us typical, 30 us worst cast, which is just fast enough.

Of course, the DAC is "only" 12 bits without any filtering, and a relatively weak signal that can't directly drive headphones. My intention has always been to support audio with and without the codec board. The library also supports using both ways simultaneously.

fnj
12-15-2013, 07:15 PM
This looks nice indeed! Good design choices.

adrianfreed
12-17-2013, 03:31 AM
Many of the now-highly-appreciated first digital synths used 12 bit dacs (and 8-bit samples!) so with care, good results can be obtained with the teensy 3.
I did a quick 16-bit update of an old 8-bit singing voice synth. (SAM) and it sounds a lot better on Teensy 3!

Nantonos
12-31-2013, 07:38 AM
Folks following this thread should read an update Paul just posted (http://forum.pjrc.com/threads/24743-H-Pyle-s-I2S-library-settings-help!?p=39254&viewfull=1#post39254) regarding plans for the first library release and first hardware release.

virtualdave
12-31-2013, 02:34 PM
Thanks for the re-direct! Can't wait!!

PaulStoffregen
01-03-2014, 12:43 AM
Just a quick update, in case anyone's wondering what's up with the audio board.

We've been testing and packaging them today. There was a minor setback where 3 of the pads (for the optional volume/parameter pot) didn't line up well with the bed-of-nails test fixture. I ended up removing those nails and Erin is manually checking those 3 pins on every board with a multimeter.

My hope is to get the board buy-able on the website sometime tomorrow or Saturday. We'll start actually shipping boards on Monday. The first beta software release will be on Monday.

1267
(click for large image)

PaulStoffregen
01-03-2014, 01:04 PM
Ok, here's the link to order an audio adaptor board.

http://www.pjrc.com/store/teensy3_audio.html

Odds are good we might start shipping them today, but if not, they'll certainly ship on Monday.

As you can see, I still have a lot of work to on documentation, and an initial release of the library. That will be coming this weekend. The library will be "beta" for some time, partly because many planned objects and examples are still missing, but also because the APIs might incompatibly change.

I'll post an announcement next week, once the software and documentation are online. But for anyone who's been following this thread, you can get a board early if you want. ;)

PaulStoffregen
01-03-2014, 07:52 PM
Audio boards are shipping today! :)

Documentation and code coming this weekend........

mattomatto
01-03-2014, 08:15 PM
Awesome. Shame I'm in the UK, will try and get cool-components to get some in and save me the shipping!

Also Paul, can you give any guidelines on how to help contribute to the audio library once it's up?

Thanks.

PaulStoffregen
01-03-2014, 08:19 PM
... in the UK

Floris.cc (http://floris.cc/shop/en/) (in the Netherlands) might be getting a small quantity of these boards next week. If you don't see them appear on his site, you might contact Pieter Floris (https://www.facebook.com/pieter.floris) and ask for one.

mattomatto
01-03-2014, 08:23 PM
Thanks, will give that a try!

mortonkopf
01-03-2014, 10:56 PM
I get my Teensys from Pieter Floris, always helpful, and fast to ship.

jstsch
01-03-2014, 11:39 PM
Fantastic! Can't wait :)

MickMad
01-04-2014, 03:13 AM
I really can't wait to test the Audio library and to adapt my USB Audio library to integrate with it :)

scswift
01-04-2014, 03:40 AM
I grabbed a bunch as promised. I've got big plans for these!

scswift
01-04-2014, 04:30 AM
I decided to reply to the other thread here since it was off topic there:



Feedback from several people indicated line in/out would usually involve soldering wires to a front panel or some other board. I really did consider adding more jacks, RCA or headphones, but ultimately small size and lower cost won over convenient jacks.


Small size is important to me. Even more so than lower cost. But for my purposes I intend to install these in both large and small enclosures along with an amplifier module of suitable size. For the small enclosures, a little 3W amplifier module will do, and as those don't have jacks on them anyway, solder pads are fine. But for larger projects, a 10W or greater amplifier is needed, and those almost always have a 3.5mm jack for input. And the convenience of just purchasing an audio cable and plugging it in cannot be understated. For one-off projects, sure, it's easy enough. But if you start selling in some volume, there's no joy in spending hours crimping hundreds of connectors.

What would be really sweet would be if there were a way to select what pins the 3.5mm jack is connected to. If you added some solder jumpers to the bottom of the board it wouldn't cost anything or increase the size of the board and you could have one pair select between gnd or vgnd, and several more would allow you to select what the tip and ring are connected to. This setup would even allow for weird outside cases like headsets which have a mic and an earpiece on a single jack.

Nantonos
01-04-2014, 12:58 PM
Floris.cc (http://floris.cc/shop/en/) (in the Netherlands) might be getting a small quantity of these boards next week. If you don't see them appear on his site, you might contact Pieter Floris (https://www.facebook.com/pieter.floris) and ask for one.
Iasked him yesterday as soon as I saw your announcement. More enquiries always good to establish demand, of course.

MickMad
01-04-2014, 02:10 PM
Iasked him yesterday as soon as I saw your announcement. More enquiries always good to establish demand, of course.

I might get one audio board from Floris too, I ordered my first Teensy 3.0 from him ;)

jstsch
01-04-2014, 02:29 PM
Heh, I also emailed Pieter. He expects to receive them in the coming week :)

Regarding the board: I'm very happy with it having a 3.5mm jack, a small headphone amplifier and a SD-slot. Why? It makes prototyping just so much smoother. If you want to mass produce (100+) anything and there are bits you don't need, then you're gonna make a new PCB anyway.

PaulStoffregen
01-05-2014, 12:47 AM
Updated the audio board page (http://www.pjrc.com/store/teensy3_audio.html) with more photos and technical info. Probably no big surprises for anyone who's followed this thread.

PaulStoffregen
01-05-2014, 01:50 AM
The audio library initial release is now available.

Please discuss the library and audio board on this new thread:

http://forum.pjrc.com/threads/24793-Audio-Library

daperl
01-05-2014, 04:41 PM
http://www.pjrc.com/store/header_14x1_d.html

Can you post a picture of these 14x1 pins. Thanks.

MichaelMeissner
01-05-2014, 06:06 PM
http://www.pjrc.com/store/header_14x1_d.html

Can you post a picture of these 14x1 pins. Thanks.
I suspect it is just the 14 pin version of this: http://www.pjrc.com/store/header_5x1_d.html

neslekkim
01-24-2014, 07:02 PM
Probably going to order this board, but some question

What is the technical name of that header? (trying to find it otherplaces, they looks nice for some other projects I have)
The flash-chip, are you going to sell that?, I'm not very keen on going to mouser for an order, which will give me $30 in shipping.

Is there any plans for adding midi input?, or are there enough io left to make some adapter?

PaulStoffregen
01-24-2014, 07:36 PM
What is the technical name of that header? (trying to find it otherplaces, they looks nice for some other projects I have)


They're sometimes called "spacer" headers.



The flash-chip, are you going to sell that?, I'm not very keen on going to mouser for an order, which will give me $30 in shipping.


There is currently no software support for the 8 pin SPI flash chip. Don't waste $30 in shipping for it, since you won't be able to use it. Well, not unless you write all the code, of course!



Is there any plans for adding midi input?, or are there enough io left to make some adapter?

A big 5 pin DIN connector would probably increase the PCB size by 50%. It seems unlikely it will be added.

But there are plenty of pins unused by the audio board, including pin 0 to receive 31250 baud serial. You could probably wire up a 5 pin DIN and PC900 optocoupler and run the signal to pin 0, using the MINI 3.2 library.

At the end of the audio adaptor page is a diagram which shows the pins used by the audio and SD card.

http://www.pjrc.com/store/teensy3_audio.html

11 I/O pins are unused by the adaptor, plus the CS pin for the SPI flash, which isn't connected unless you solder a flash chip. But there's not much point to adding that chip yet, because there's no software support at this time.

The software does support playing WAV files from the SD card, and short clips from the internal flash of the MK20 chip on Teensy 3.1.

scswift
01-24-2014, 08:09 PM
Probably going to order this board, but some question

What is the technical name of that header? (trying to find it otherplaces, they looks nice for some other projects I have)


You can get them here:
http://www.digikey.com/product-search/en?FV=fff40016%2Cfff80424%2C1640001%2C1680001&mnonly=0&newproducts=0&ColumnSort=901&page=1&stock=1&pbfree=0&rohs=0&quantity=&ptm=0&fid=0&pageSize=25

The stack height parameter tells you the distance between the two boards you're mating. So a .200" stack height is a header with two of the black plastic spacers butt up against one another, while a .300" will have an empty space the thickness of one of those spacers between, like the one in the PJRC store. The $20 one there has the long pins on one side like PJRC, suitable for breadboards, while the $11 one has short pins on both sides.

scswift
01-24-2014, 08:16 PM
11 I/O pins are unused by the adaptor, plus the CS pin for the SPI flash, which isn't connected unless you solder a flash chip. But there's not much point to adding that chip yet, because there's no software support at this time.

The MCLK pin can be used as well if you don't have the flash chip in place, I assume.

PaulStoffregen
01-24-2014, 08:56 PM
The MCLK pin can be used as well if you don't have the flash chip in place, I assume.

From the web page.



Audio data uses I2S signals, TX (to headphones and/or line out) and RX (from line in or mic), and 3 clocks, LRCLK (44.1 kHz), BCLK (1.41 MHz) and MCLK (11.29 MHz).

Nantonos
01-25-2014, 01:07 AM
Is there any plans for adding midi input?, or are there enough io left to make some adapter?

There is already a USB connector, and a very capable USB MIDI implementation - just select it from the menu. (this does require a USB host, such as a computer, unlike the point-to-point DIN MIDI. On the other hand, throughput is much higher so you don't get congestion botlenecks).

neslekkim
01-25-2014, 02:04 PM
They're sometimes called "spacer" headers.


Great, will try to look for that.



There is currently no software support for the 8 pin SPI flash chip. Don't waste $30 in shipping for it, since you won't be able to use it. Well, not unless you write all the code, of course!


If it was sold in the same manner as you sell the headers and the thumbweel resistor, I would'nt waste shipping :), but if there is support or not, with time, someone would do it, I would definately try to do something when I get up to speed on this, but wanted to check before buying the audioadapter.



A big 5 pin DIN connector would probably increase the PCB size by 50%. It seems unlikely it will be added.

But there are plenty of pins unused by the audio board, including pin 0 to receive 31250 baud serial. You could probably wire up a 5 pin DIN and PC900 optocoupler and run the signal to pin 0, using the MINI 3.2 library.

At the end of the audio adaptor page is a diagram which shows the pins used by the audio and SD card.


An pinout would also be ok.
The picture is fine, if it was overlayed with the teensy layout :) (I really dig the card that comes with teensy 3.0 and 3.1, everyone should make something like that)
Hm, of course, there is an sd-card, that might reduce the need for the flash somewhat, how is the speed of reading from the sdcard comparing to the flash? (idea for the flash was to upload samples..)



http://www.pjrc.com/store/teensy3_audio.html

11 I/O pins are unused by the adaptor, plus the CS pin for the SPI flash, which isn't connected unless you solder a flash chip. But there's not much point to adding that chip yet, because there's no software support at this time.

The software does support playing WAV files from the SD card, and short clips from the internal flash of the MK20 chip on Teensy 3.1.

btw, I didn't get email to tell that someone answered this post, I had to go looking for it, even if I turned it on, is it turned of serverside?

neslekkim
01-25-2014, 02:05 PM
There is already a USB connector, and a very capable USB MIDI implementation - just select it from the menu. (this does require a USB host, such as a computer, unlike the point-to-point DIN MIDI. On the other hand, throughput is much higher so you don't get congestion botlenecks).

Yes, but why always involve an computer? ;)

PaulStoffregen
01-25-2014, 05:53 PM
If you really want serial MIDI, you certainly can use the MIDI 3.2 library and a small amount of hardware to get it.

http://www.pjrc.com/teensy/td_libs_MIDI.html

neslekkim
01-25-2014, 08:00 PM
That looks fine, have all parts, except for the pc900, but I have the 6n138 so that should be just as well..

Nantonos
01-26-2014, 03:44 AM
That looks fine, have all parts, except for the pc900, but I have the 6n138 so that should be just as well..
Yes, that optoisolator should be fine. What passes for a MIDI electrical spec (http://www.midi.org/techspecs/electrispec.php) says "Opto-isolator shown is Sharp PC-900. HP 6N138 or other can be used with changes. "
In practice I have not seen anyone make any changes.

tzif
04-26-2014, 05:33 PM
Here's what the audio shield will probably look like....

906 905

http://oshpark.com/shared_projects/2k03eMcK

Hello
Thank you for a great forum and great help
I managed to get the Greber files for the Audio shield for Teensy
Is there a way that you can direct me to the schematic?

Please advise

mattomatto
04-26-2014, 06:07 PM
Check the sgtl5000 data sheet for the schematic. I'm using that at the moment. Haven't received my first board to test yet though.

tzif
04-26-2014, 06:10 PM
Hello mattomatto
Thank you for your quick replay
I am looking at the data sheet
I am tring to do reverse engineering for the connection of the SD card


Thank you again

PaulStoffregen
04-26-2014, 10:54 PM
I am tring to do reverse engineering for the connection of the SD card


http://www.pjrc.com/store/teensy3_audio_pins.png