Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 18 of 18

Thread: 3.6 as a Modular Synthesizer DSP

  1. #1
    Junior Member
    Join Date
    Dec 2016
    Posts
    7

    3.6 as a Modular Synthesizer DSP

    I already know something like this is possible and will be basing my path forward on successful projects like Ornament and Crime https://github.com/mxmxmx/O_C My own experience with microcontrollers is a graduate level mechatronics course that mainly focused on motor controllers and the like as well as some hobby stuff. My coding experience is every day on the job, so no worries there. I also have built a number of synthesizer modules from schematics; and my own variations on designs.

    What I want to know is if my approach is sound. For components I am considering:
    DAC8568 an octal 16 bit DAC http://www.ti.com/lit/ds/symlink/dac8568.pdf
    ADS8332 an octal 16 bit ADC http://www.ti.com/lit/ds/symlink/ads8332.pdf
    3.5" TFT 320x240 Touchscreen HXD8357D HXD8357D https://www.adafruit.com/products/2050
    Extra SPI memory with 6 23LC1024 https://github.com/FrankBoesing/memoryboard
    Possibly extension with capacitive touch interface through SPI.
    Various opamps to scale and offset voltages.
    I could draw out a schematic, but it would look quite similar to the Ornament and Crimes linked above.

    Questions:
    My first questions are how would you lay out the SPI interface? From what I have been reading it would be a good idea to put the TFT on SPI0 by its self (very interested in the high performance DMA library). Would it be best to put the DAC and ADC on separate SPI? Or will they play nice at 44khz on the same SPI? Basically is there enough SPI I/O to go around at audio rates?

    Concept of Operations:
    An image of the module layout I am planning
    http://www.sinphi.com/synths/effluvium/DSP_001.png

    At the core it is a Teensy 3.6 microcontroller board with 16 bit ADC/DAC and enough memory for up to 9 seconds of audio delay or sampling. The 3.5 inch touch screen allows for quick and direct selection of options. The I and J encoders allow for selection within those parameters. Pressing J progresses into a menu and I backs out. Holding I for two seconds will return to the root menu. The I encoder is used to scroll through parameters and the J encoder is used to edit the parameter.

    There are 12 inputs: 4 trigger/gate inputs and 8 ADC configurable control voltages. The 8 DAC outputs are capable of 10 Volt peak-to-peak operation. Triggers can be used for clocks, event triggers, envelope gates, retrigger, etc. The ADC inputs accept audio or control voltages (CV). The outputs can be bipolar or unipolar depending on the application with CV or audio output.
    Last edited by Sin_Phi; 01-06-2017 at 05:32 PM.

  2. #2
    Interesting... I've just been thinking of something similar. Although I was looking at stereo 24bit/96kHz ADC+DAC. An open source project similar to the O&C but for audio processing based on the 3.5/3.6 would be a great resource. Especially with the FPU, it should open up use of different C++ audio libraries that rely on floating point audio buffers.

  3. #3
    Senior Member
    Join Date
    Feb 2013
    Posts
    563
    neat, our vague schemes for an OC mk2 looked somewhat similar, minus the extra SRAM; and still focused on CV applications, mainly.

    fwiw, the main bottleneck in the existing version was/is the single SPI port on the MK20; running the display and DAC off the same bus was ok for the intended use (quantizing), but that's what limits the sample rate to 16.7kHz. without the display, IIRC the DAC8568 managed about ~ 80kHz (all 8 channels, using similar SPI code as does OC, simple sine waves); so with the T.3.6 out, and both a DAC and an ADC involved, i'd definitely make use of the several SPI ports, or maybe even use the TFT 8 bit interface (i think something along these lines happens in the Mordax Data). don't know which one would be more effective or whether there's much of a difference.

    i'd also imagine that for audio stuff an i2s codec might be an alternative worth considering, also cheaper, even if that might limit the number of i/o. maybe there's a suitable 4 in / 8 out one, which could be made to work (e.g. AD1938 ?). or some combination thereof (the e-301 block diagram) is quite interesting, using a olimex/Sitara thingie though); or you could use two, la 4ms DLD. the DLD also features a cheap DRAM (256Mbit), which, in terms of $, looks more appealing than the multiple SPI RAM solutions; 16 bit parallel interface though.

  4. #4
    Senior Member
    Join Date
    Dec 2014
    Posts
    134
    Ive been considering doing an open source utility project of this nature as well, I would love to make it a collaborative effort. You know I'm a fan of you mxxx and the OC code now is incredible, and builds a fantastic inner platform for apps. what I have been designing as a concept for the teensy 3.6 open source based module is rather open ended, and I want for it to have easily extensible utilities. Think of it like 4 ES Disting modules with an intuitive screen setup, and nicely formatted libraries that deal with all of the backend BS so that anyone familiar with basic programming techniques could quickly plug in the USB or SD card and create new applets. The main concept work I have done thus far I am willing to provide, and I have outlined a very flexible DSP object based on what I have been exploring in the FV-1 assembler language, that basically allows for the creation of loads of different DSP algorithms to be rapidly designed and tested at different levels of abstraction. I also have finished the back end storage and recall data bus system, and nearly finished a nice library for its implementation that takes out all the guess work of designing a module that will accommodate it!

  5. #5
    Senior Member
    Join Date
    Dec 2014
    Posts
    134
    Quote Originally Posted by Sin_Phi View Post
    Concept of Operations:
    An image of the module layout I am planning
    http://www.sinphi.com/synths/effluvium/DSP_001.png

    At the core it is a Teensy 3.6 microcontroller board with 16 bit ADC/DAC and enough memory for up to 9 seconds of audio delay or sampling. The 3.5 inch touch screen allows for quick and direct selection of options. The I and J encoders allow for selection within those parameters. Pressing J progresses into a menu and I backs out. Holding I for two seconds will return to the root menu. The I encoder is used to scroll through parameters and the J encoder is used to edit the parameter.

    There are 12 inputs: 4 trigger/gate inputs and 8 ADC configurable control voltages. The 8 DAC outputs are capable of 10 Volt peak-to-peak operation. Triggers can be used for clocks, event triggers, envelope gates, retrigger, etc. The ADC inputs accept audio or control voltages (CV). The outputs can be bipolar or unipolar depending on the application with CV or audio output.


    The touch screen board link doesn't seem to work. I have a few ideas on layout if you are open to them.

    DMA and SPI is a very good thing to be considering at this point. Also huge is possibly using parallel screen communication rather than SPI, though I don't know yet much about how to implement that, or if people have done parallel DMA communication libraries etc.. to reference.

    I myself am wishing there was a bit more info on Paul's DMAchannel library built into teensyduino. I went into the package of arduino and opened up the .c and .h files, and there were some comments but a simple example would be very useful. Ive been reading this PDF guide from NXP/ freescale on how to use DMA for SPI communications, and I will find the link and post here. It actually breaks down the register commands/settings and seems relatively flexible and easy to understand.

  6. #6
    Quote Originally Posted by MacroMachines View Post
    Ive been considering doing an open source utility project of this nature as well, I would love to make it a collaborative effort. You know I'm a fan of you mxxx and the OC code now is incredible, and builds a fantastic inner platform for apps. what I have been designing as a concept for the teensy 3.6 open source based module is rather open ended, and I want for it to have easily extensible utilities. Think of it like 4 ES Disting modules with an intuitive screen setup, and nicely formatted libraries that deal with all of the backend BS so that anyone familiar with basic programming techniques could quickly plug in the USB or SD card and create new applets. The main concept work I have done thus far I am willing to provide, and I have outlined a very flexible DSP object based on what I have been exploring in the FV-1 assembler language, that basically allows for the creation of loads of different DSP algorithms to be rapidly designed and tested at different levels of abstraction. I also have finished the back end storage and recall data bus system, and nearly finished a nice library for its implementation that takes out all the guess work of designing a module that will accommodate it!
    Very interesting! The DSP object you mention - would that allow for floating point buffers? The reason I ask is I have been working with the JUCE C++ library, and there is lots of floating point DSP code out there using that library (and others I'm sure). I've been wondering about porting a mobile audio app written in JUCE to a hardware platform with the Teensy 3.6, as an alternative to embedded linux.

  7. #7
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,473
    TDM on the I2S port is probably the most realistic way to get 8 channels at full audio bandwidth.

    Here's a link to TI's website, which hopefully brings up a lot of parts with TDM.

    http://www.ti.com/lsds/ti/audio-ic/a...;TDM&p2626=1;1

    Maybe other TDM-capable chips exist? A first step would be to choose a TDM chip for testing...

    One minor issue is also supporting I2C to program the TDM offsets in each chip, as well as many other parameters. TLV320AIC3105 (the cheapest part on TI's list) appears to have a fixed I2C address of 0x18. There aren't any pins to configure the chip to different I2C addresses, which means any practical design will probably need an I2C mux and a couple extra pins to control it.

  8. #8
    Senior Member bmillier's Avatar
    Join Date
    Apr 2016
    Location
    Halifax, N.S. Canada
    Posts
    187
    @Paul. That fixed I2C address is an interesting observation, since many audio products that need 8 CODEC channels can just as easily need 16, 24 channels. So this would seem to be a shortcoming in the TI design, unless TI has different versions with different BASE addresses, like they do with the PCF8574 , PCF8574A I/O expander chips

  9. #9
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,473
    Yeah, TDM feels like a niche feature.... important enough for a (probably very small) increase in silicon area, but obviously Texas Instruments believes virtually all of their customers will use only 1 of these chips. Extra pins are a scarce resource in IC design! I'm pretty sure this exists because TI put TDM into their line of DSP chips many years ago, so they probably want their own codec chips to at least be able to support it.

    Freescale probably had a similar thought process in designing their I2S peripheral. TDM only adds a small extra cost, since it's pretty much the same circuitry with just a little more logic. I'm pretty sure the thinking was something along the lines of a tiny extra cost adds another feature, and maybe it would someday lead to their products competing with TI DSP chips.

    The situation is also analogous for PJRC. TDM support isn't somewhere I can spend a lot of time. But it is pretty awesome, and if it allows a few modular synth builders to get the extra full bandwidth channels they need, but I'll put a little work into supporting it. Maybe? But it's going to look sort-of like Freescale's and TI's effort... I'll almost certainly go to the trouble of making a test board with one of these TI codec chips (well, with 4 or 6 or 8 of them) and get the code working. But after that's tested, my response for all things TDM is probably going to look like "it works on the test board, if you need something different, you're on your own from here!"

    So if anyone modular synth builder types are paying attention, now's your chance to influence which codec chip ends up being the on the test board. I'm leaning towards the least expensive ones (TLV320AIC3105) with the basic idea that if it works well with the cheapest part, hopefully the more expensive ones are likely to only add features and might work too. At least that seems safer than going with a spendy part and later discovering some dependency on a feature not present in the lower spec chips got worked into the test board and audio library code. Remember, I'm probably going to only ever make 1 TDM test board and only really put substantial work into supporting TDM just once. The long-term code maintenance is going to have a strong flavor of "well, it works with the TDM test board".

  10. #10
    Senior Member bmillier's Avatar
    Join Date
    Apr 2016
    Location
    Halifax, N.S. Canada
    Posts
    187
    I agree that they are "niche" for Teensy market and the consumer market too. But, in the audio recording business, they use lots of TDM CODECs in multichannel (digital) recording mixers, and almost none of these would be only 8 channels wide- mostly 16 - 32 main channels and 8 or more AUX channels.
    But I took a look at the TI datasheet in the link and see that these chips are I2C/SPI. So, in professional use, they could handle Multiple CODECs by using the SPI bus and discrete -CS lines.
    I like the idea of a Teensy compatible board with the TI TLV320 CODEC on it. Of course having the audio library support it would be a big plus. I'm writing some of my own audio library routines now, but that would have been unthinkable if I had to start from scratch, ie without the framework you wrote.
    The T3.6 probably has enough horsepower to handle more than one 8 channel device simultaneously.
    I just finished a Hammond tone wheel organ/Leslie speaker emulation project, and managed to get everything going fine with my (Kickstarter) T3.5 I thought I'd need the T3.6 but by the time the 3.6 boards arrived, I had tuned up the code enough that the T3.5 was plenty. Great boards!

  11. #11
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,473
    Here's several TDM chips I found with a bit of searching...

    Cirrus Logic CS4244 - 4 ADC, 4 DAC, $7.21 Digikey 100 qty
    Cirrus Logic CS42432 - 4 ADC, 6 DAC, $8.05 Digikey 100 qty
    Cirrus Logic CS42448 - 6 ADC, 8 DAC, $8.87 Digikey 100 qty
    Texas Instruments TLV320AIC3105 - 2 ADC, 2 DAC, $3.54 Digikey 100 qty
    Texas Instruments TLV320AIC33 - 2 ADC, 2 DAC, $6.59 Digikey 100 qty
    Maxim MAX98090 - 2 ADC, 2 DAC, $3.69 Digikey 100 qty
    Analog Devices AD1937 - 4 ADC, 8 DAC, $8.39 Digikey 100 qty
    Analog Devices AD1938 - 4 ADC, 8 DAC, $7.95 Digikey 100 qty
    Analog Devices AD1939 - 4 ADC, 8 DAC, $8.39 Digikey 100 qty

    Not all of these are designed to play nice and share a TDM bus with more chips. TI TLV320AIC3105 definitely does. Looks like Cirrus Logic CS42448 (the most "bang-for-buck" chip) doesn't share, so we might be limited to only 1 or 2 of these chips.

    If I do anything with TDM, which is a pretty big *if*, it's only going to happen once with 1 part. Well, unless of course tons of people start using TDM with Teensy... but I'm pretty sure this many-channel stuff is going to be fairly rare. Still, it's so awesome, kinda want to help make it happen even if only a few people ever really use it.

  12. #12
    Quote Originally Posted by mxxx View Post
    i'd also imagine that for audio stuff an i2s codec might be an alternative worth considering, also cheaper, even if that might limit the number of i/o. maybe there's a suitable 4 in / 8 out one, which could be made to work (e.g. AD1938 ?). or some combination thereof (the e-301 block diagram) is quite interesting, using a olimex/Sitara thingie though); or you could use two, la 4ms DLD. the DLD also features a cheap DRAM (256Mbit), which, in terms of $, looks more appealing than the multiple SPI RAM solutions; 16 bit parallel interface though.
    That DLD looks interesting. I like the fact the user can update the firmware from an audio file - very fitting for synth geeks! Seems like a good platform on which to base an audio processing module. I wonder what advantages / disadvantages there would be in using an STM32F4 instead of a Teensy? The main one I see is the ease of programming the Teensy without an expensive programmer device.

  13. #13
    Junior Member
    Join Date
    Dec 2016
    Posts
    7
    Thank you all for the great replies. Looks like I have a lot more research to do into TDM and such, thanks for putting me on the right path to more understanding here. The TDM is all new information to me, but it looks like a good fit to my application. If the DRAM is good enough for the DLD it is probably good enough for me, that is a feature set I would like to emulate. Will that work with DMA?

    Bmiller, sounds like a really cool project! Would be interested to see that working.

    Fixed the link to the touch screen. Also will probably get rid of the encoders and have all control go through the touch screen, lets me add 4 gate/trigger outputs. Less knob wiggling fun, but simplifies the interface.

    If 2x CS42448 ends up working that is probably plenty. I probably don't need more than that for I/O for this application and wouldn't want it from the usability stand point. The TI TLV320AIC3105 looks like a 6 and 6 not 2 and 2? Oh i see it is some kind of channel select. 8 I/O is preferable as far as sequencing applications are concerned for music synthesis. The TI does have some nice other DSP functions built in though. All of these are very tiny ICs I don't look forward to soldering, will have to stay away from the BGA for me at least.

  14. #14
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,473
    Quote Originally Posted by Sin_Phi View Post
    The TI TLV320AIC3105 looks like a 6 and 6 not 2 and 2?
    Read the datasheet carefully. Just because there are 6 pins doesn't mean there are really 6 ADCs. The pins are switched.

  15. #15
    Junior Member
    Join Date
    Dec 2016
    Posts
    7
    Yeah, I am now diving into the codec datasheets. Need to do more research so I can ask the right questions. I am eyeing the TI PCM3168A right now with its 6ADC/8DAC, no switching. http://www.ti.com/product/PCM3168A/description There is a nice write up on an application here as well http://www.ti.com/lit/ug/slou366b/slou366b.pdf, see page 30 and 41 for schematic with the PCM3168A.

    And a 15min training module on the thing if you feel like spending the time... https://www.youtube.com/watch?v=3uUizz8gsoo
    Last edited by Sin_Phi; 01-06-2017 at 09:41 PM.

  16. #16
    Senior Member
    Join Date
    Feb 2013
    Posts
    563
    Quote Originally Posted by PaulStoffregen View Post
    Here's several TDM chips I found with a bit of searching...

    [ ...]

    Not all of these are designed to play nice and share a TDM bus with more chips. TI TLV320AIC3105 definitely does. Looks like Cirrus Logic CS42448 (the most "bang-for-buck" chip) doesn't share, so we might be limited to only 1 or 2 of these chips.

    If I do anything with TDM, which is a pretty big *if*, it's only going to happen once with 1 part. Well, unless of course tons of people start using TDM with Teensy... but I'm pretty sure this many-channel stuff is going to be fairly rare. Still, it's so awesome, kinda want to help make it happen even if only a few people ever really use it.
    mmh, i'd also think this might be something of a niche requirement. but *if* this is going to happen, for the sake of DIY, i'd vote for one that can be soldered by hand easily, ie CS42432, CS42448, or AD1937/38/39 rather than the TI or Maxim ones. or would the pretty big if involve a PJRC board, la the audio adapter?

    fwiw, there's an open source PCB for the AD1938 ctag-face-2-4, which might come in handy for testing.

    Quote Originally Posted by adamski View Post
    That DLD looks interesting. I like the fact the user can update the firmware from an audio file - very fitting for synth geeks! Seems like a good platform on which to base an audio processing module. I wonder what advantages / disadvantages there would be in using an STM32F4 instead of a Teensy? The main one I see is the ease of programming the Teensy without an expensive programmer device.
    don't know, superficially the specs look fairly similar, as does price. from a DIY perspective it probably doesn't matter much, or will depend on the objective / details. there's cheap solutions for programmers (ST link, discovery boards, etc) and many open source examples of STM32F4 based audio devices, so that's not necessarily a criterion. the STM32F4 ADCs are notoriously noisy, i don't know how MK66 compares.

  17. #17
    Junior Member
    Join Date
    Sep 2019
    Posts
    19
    This is very interesting

    any updates!

  18. #18
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,473
    This is a very old thread, from before the audio library supported TDM protocol (up to 16 channels input and 16 channels output) and the CS42448 chip (6 inputs, 8 outputs).

    Please see this (newer, but also old) thread for where TDM and CS42448 were done (in April 2017):

    https://forum.pjrc.com/threads/41371...l=1#post138705

    Here is a link to the PCB shared on OSH Park. Click the "Project description" button on that page to see all the info.

    https://oshpark.com/shared_projects/2Yj6rFaW

    Several people have built this PCB and confirmed it worked, and of course the 3 I personally soldered all worked. If you want a lot of inputs & outputs, use the CS42448 chip and TDM.

    I'm now going to close this very old thread.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •