Updating Design Tool for Teensy 4.0 & 4.1

PaulStoffregen

Well-known member
I've started updating the Audio Design Tool for all the new inputs and outputs on Teensy 4.

Here is a test copy. (planning to update the main site after some feedback)

https://www.pjrc.com/teensy/gui2/

Please take a look and tell me if I've missed anything? Or made mistakes?

Several of the new objects don't have any documentation yet. Those say only "undefined" in the documentation panel. Contributions welcome....

But mainly I'm hoping for feedback on the ones which are written. Have I missed any details, like pins for specific boards, important notes about what does and doesn't work, and so on?
 
I'm just glancing at it right now. Note, all of these are suggestions. If it is not worth the return on investment, feel free to drop stuff.

I'm beginning to wonder it if would be better to have each of the major categories (input, output, mixer, play, record, synth, effect, filter, analyze, control) to be pull down menus. It is getting unwieldy to scroll down through all of the different entries. Of course it will make it slightly more complicated. It would be helpful if the entries list what Teensy is supported when you hover over the entry.

For many people, it would probably be useful to have an entry for the audio shield that adds all of the necessary interconnects. Perhaps a Prop Shield also.

As we have discussed before, we really need a FILE layer to go between the audio readers (RAW, WAV, etc.) and output. Otherwise, we will need a N*M matrix to support all of the different readers (RAW, WAV) and file system combinations (SD revision 1, SD-beta, SPIFFS, etc.). In addition, we should think about having multiple instances of say SD readers (i.e. on the Teensy 3.5/3.6/4.1, you could possibly want to use both the built-in SD card reader, and the SD card reader on the audio shield).

With the Teensy 4.1/3.6, we should support reading files from removable devices like USB flash memory sticks. This may be a longer term thing. Even longer term might be incorporating networking.

Also longer term, but possibly worth thinking about, particularly with a FILE layer, is having standard output devices to write WAV, RAW, etc.

It would be nice if we could include FrankB's MP3 reader in the basic set.

It would probably help some people to have a Teensy box that says what Teensy you are building for, and then all of the devices that don't work for that Teensy will be grayed out. For example, I answered a question today about a user trying to use AudioOutputAnalogStereo on a Teensy 3.2. Obviously, you do want a combination Teensy that will allow anything.

Once in awhile, I've wanted a mixer that had more than 4 inputs. Yeah, you can add multiple mixers, but it can be useful to have one object. Particularly now that you have hex and quad inputs and outputs it would be helpful to have mixers with more inputs.

Having an amp that reads from an analog pin (instead of having the user do the appropriate read and call the function) can be useful. For a volume switch, it would be useful if the same analog pin could apply to multiple inputs and pass them on to multiple outputs.

It would be nice if the Export function did not automatically include SD.h and SerialFlash.h unless the user actually configures those devices. In particular, the threads that complain about wanting to use SdFat-Beta, while the tool always puts out SD.h.

I presume SPDIF2/3 are for use with the Teensy 4.0/4.1.

For the standard SPDIF, it mentions using pin 22. It is probably helpful to clarify that this is for the software S/PDIF that works on any digital pin. I don't know if we want to automatically switch to using pin 14 on the Teensy 4.0/4.1 to use the hardware S/PDIF automagically, or suggest that the user use one of the other S/PDIF modules. In any case, it would probably be useful if we could provide an override for the pin used.

It is good to see that all 5 of the I2S1 pins are now being handled by the tool.

Given that the Teensy 4.1 has alternates for OUT1A and IN1 (pins 39, 38) we probably should have some way to override using the standard pins 7/8. I2S and others should mention this.

In the I2S description, we say:
Normally, this object is used with the Audio Shield, which is controlled separately by the "sgtl5000" object.

I would suggest changing this to something like:
Typically, this object is used with the Audio Shield, which is controlled separately by the "sgtl5000" object. It can also be used with other I2S implementations as well. Some other I2S implementations might provide CODECs that you can control, others might just use the basic I2S stream.
 
For what it's worth, a set of tabs, each with their own list of things, might be better than a pulldown menu.
Or a popup menu to select a set of things, and then the list of things.
You can get very close with the current "accordion" to automatically close other categories when one particular category is opened.

A mixer with a variable number of inputs would be sweet. Just keep dragging things to it, and it adds new input pins.

Is there some way to get the PWM output to work on Teensy 4 series? The lack of a DAC is a bit annoying.
Heck, an 8-bit DAC that uses 8 digital pins and a RC filter output might be good enough for the kinds of toys I build!

Agree on using hardware S/PDIF for 4 series.
 
Is there some way to get the PWM output to work on Teensy 4 series? The lack of a DAC is a bit annoying.
Heck, an 8-bit DAC that uses 8 digital pins and a RC filter output might be good enough for the kinds of toys I build!

If you don't use the main SPI bus, using MQS (pins 10 and 12) might be a possibility. At least with the Teensy 4.1, you don't have to solder to the underneath pads to get access to the second SPI bus (assuming you want to use a fast SPI display).

If you only need mono sound, then using one of the MAX98357 based boards might be useful. These boards use I2S, and mix the L/R channels, and amplify the sound for a mono speaker.:
 
So many good but long term software suggestions... much of this stuff is planned. The file abstraction is the one that’s on my list for 1.53.

Right now, my goal is merely documentation. Not looking to change the JavaScript code or html/css layout right now. My immediate goal is to get all the stuff that’s currently in the library available from the design tool, and fully documented.
 
@PaulStoffregen for the tool:

The list of compatible chips says:

Compatible CODEC Chips:
STGL5000
TLV320AIC3206
AK4558
Compatible DAC Chips:
PCM5102A
PCM1808
PCM5242
CS4344

The list of supported chips in the sources say:
#include "control_sgtl5000.h"
#include "control_wm8731.h"
#include "control_ak4558.h"
#include "control_cs4272.h"
#include "control_cs42448.h"
#include "control_tlv320aic3206.h"

Should the WM8731 be added to the docs? How about CS4244 (additional to 42448) and the PCM series DACs?



@MichaelMeissner If I'm going to use a board, I might as well use a DAC!
The CS4334 looks very easy to integrate, as it's self-configuring and doesn't need any I2C setup.
Comes in an easy-to-solder SOIC 8-pin package, too, which is 2 pins less than the 4344 :)
In fact, someone could build a 10-channel output board with a BOM in the $15 range for the Teensy 4.1 on top of a few copies of that chip ...
And it has the option to synthesize the bit clock from the master clock, too, so you can save some pins on the Teensy for other functions if you want.
 
I've added more, all the inputs & outputs have at least some documentation.

https://www.pjrc.com/teensy/gui2/

I added WM8731 to the list of known compatible I2S chips.

On CS4244 and CS4334, can you point me to the forum threads or other pages where anyone has confirmed these chips work. While not an absolute hard requirement, generally I want to add chips to that list when we have a thread with a confirmed good result (ideally with a photo).

On CS42448 - while it can do I2S, so far I've only tested it with TDM, so it's mentioned in the TDM documentation but not the I2S documentation.
 
I changed the color of the 3 inputs & outputs which run at an externally controlled sample rate. I also added warning in red that they're incompatible with most of the rest of the inputs and outputs.
 
If we are listing DACs, we might want to list chips/boards that act as DACs, but have no ways to control them like we have with the SGTL5000. In particular, I've used boards with the MAX98357 and PCM5102 chips.
 
On CS4244 and CS4334, can you point me to the forum threads or other pages where anyone has confirmed these chips work.

I could have sworn I saw a 4244 description somewhere but I can't find it now.
Waiting for confirmation seems fine, no need to add mention of un-confirmed chips.
 
Once in awhile, I've wanted a mixer that had more than 4 inputs. Yeah, you can add multiple mixers, but it can be useful to have one object. Particularly now that you have hex and quad inputs and outputs it would be helpful to have mixers with more inputs.

I made a Mixer8 and offered a Pull Request to Paul. In the pull request, I also added the Mixer8 to the Audio GUI.

Of course, he may decline to accept the pull request as he might prefer to cascade 4-channel mixers (per his documentation and per your comment) rather than have additional classes that need to be maintained. It's his call.

Chip
 
this is great, good shout changing the colour of the slaves, that makes life a lot easier.

For what its worth I like having access to all the inputs, outputs etc in a large list rather than menu diving for them.
 
Of course, he may decline to accept the pull request as he might prefer to cascade 4-channel mixers (per his documentation and per your comment) rather than have additional classes that need to be maintained. It's his call.

I've learned the hard way about publishing documentation on the main website for new features before or during beta testing. That's why I'm working now to get all the documentation updated for the just-released-in-1.52 stuff. I'm not going to merge anything new until the documentation is up to date.
 
Are there forum threads or blog posts I can use for links?

I posted an example of how to use the MAX98357A in this thread that I created:

Hmmm, I've bought this PCM5102A board, but I don't recall using it. I'll see if I can find it and solder it up tonight.

I did notice this thread on the PCM5102A:
 
Last edited:
@Paul:

As a beginner with the audio library when I started tinkering with my TeensyMIDIPolySynth project, I used the GUI tool extensively as a reference, with the example sketches as additional/backup info. Would it be possible in the GUI tool to add the parameter types to the functions listed ??

For example, under the "AudioSynthWaveformMod" list of functions, it currently lists:

- amplitude(level);

Could it instead be listed as:

- amplitude(float: level);

In addition (or as an alternative), could the descriptive text for each function list the appropriate type & range for each parameter ??

For example, the description for the "amplitude(level);" function currently says:

- Change the amplitude. Set to 0 to turn the signal off.

Could it instead say something like this:

- Change the amplitude. Level type: float. Level ange: -1.0 to +1.0. Set to 0.0 to turn the signal off.

Likewise, for functions that return a result, knowing the return type would be beneficial.

For example, under the "AudioSynthToneSweep" list of functions, it currently lists:

- read();

Could it instead be listed as:

- float read();

In addition (or as an alternative), could the descriptive text for each function list the appropriate type & range for the return value ??

For example, the description for the "read();" function currently says:

- Returns the current frequency, or zero if the output is not active.

Could it instead say something like this:

- Returns the current frequency. Return type: float. Return range: 20.0 to 20000.0. Returns 0.0 if the output is not active.

I did try to dig through the source code to find some of these particulars, but being a brand new audio library user, it was not obvious to me where to find all of the info. For example, I still have not found the source containing the AudioProcessorUsage() & AudioProcessorUsageMax() functions to see exactly what they return !!


Thanks for your consideration of this suggestion.

Mark J Culross
KD5RXT
 
Back
Top