Forum Rule: Always post complete source code & details to reproduce any issue!
Page 4 of 6 FirstFirst ... 2 3 4 5 6 LastLast
Results 76 to 100 of 134

Thread: Quad channel output on Teensy 3.6

  1. #76
    Paul and/or Synthcat,

    When you tested the board, did you use an audio file off the teensy or are you using the audio input on the multiport board?

  2. #77
    Here are pictures of a few of the 7 that I have made.

    Click image for larger version. 

Name:	image.jpg 
Views:	177 
Size:	174.7 KB 
ID:	11170Click image for larger version. 

Name:	image.jpg 
Views:	152 
Size:	175.5 KB 
ID:	11171

  3. #78
    Junior Member
    Join Date
    Mar 2017
    Posts
    17
    So far I've only tested audio out from wav files on the SD card. I'll test the inputs tomorrow and let you know how they sound.

    When you play files, do they still sound crappy?

  4. #79
    Quote Originally Posted by synthcat View Post
    So far I've only tested audio out from wav files on the SD card. I'll test the inputs tomorrow and let you know how they sound.

    When you play files, do they still sound crappy?
    Just tested with audio files....they sound beautiful. So for me, it only sounds crappy when I use the boards inputs.

  5. #80
    Junior Member
    Join Date
    Mar 2017
    Posts
    17
    Hi Mike,

    I can't seem to get anything out of the inputs. Can you see if I'm' doing something wrong with the code?

    Code:
    #include <Audio.h>
    #include <Wire.h>
    #include <SPI.h>
    #include <SD.h>
    #include <SerialFlash.h>
    
    // GUItool: begin automatically generated code
    AudioInputTDM            tdm1;           //xy=555,297
    AudioOutputTDM           tdm2;           //xy=837.25,297.75
    AudioConnection          patchCord1(tdm1, 0, tdm2, 0);
    AudioConnection          patchCord2(tdm1, 2, tdm2, 2);
    AudioConnection          patchCord3(tdm1, 4, tdm2, 4);
    AudioConnection          patchCord4(tdm1, 6, tdm2, 6);
    AudioConnection          patchCord5(tdm1, 8, tdm2, 8);
    AudioConnection          patchCord6(tdm1, 10, tdm2, 10);
    AudioConnection          patchCord7(tdm1, 12, tdm2, 12);
    AudioConnection          patchCord8(tdm1, 14, tdm2, 14);
    AudioControlCS42448      cs42448_1;      //xy=883.25,490.75
    // GUItool: end automatically generated code
    
    
    
    void setup() {
      // put your setup code here, to run once:
    cs42448_1.enable();
    cs42448_1.volume(1);
    }
    
    void loop() {
      // put your main code here, to run repeatedly:
    
    }
    Click image for larger version. 

Name:	TDM_obj.PNG 
Views:	47 
Size:	13.2 KB 
ID:	11180

    I just have the TDM input object routed directly to the TDM output object, which I would think should just stream right through.
    Last edited by synthcat; 08-06-2017 at 09:18 PM. Reason: new image

  6. #81
    Syncat,

    I really appreciate your help! I just tried your code. It is missing memory, add a line like "AudioMemory(15);"

  7. #82
    Junior Member
    Join Date
    Mar 2017
    Posts
    17
    AudioMemory(16); worked. Thanks!

    I seem to be getting the same thing you are: (this should be a sine wave at 440)

    Click image for larger version. 

Name:	scope1.PNG 
Views:	65 
Size:	43.9 KB 
ID:	11185

    My guess is that this is a problem with the clock settings or the buffer, not with the hardware. It looks to me like maybe half the buffer is empty or the LRCLK is 2 times too long. Paul, do you have any ideas?

  8. #83
    Synthcat,

    I figured it out....your missing code and your o-scope output above made me think that this memory value needs to be higher....I used 300 and it sounds like heaven. Thank you for helping me working through this! I'm doing the multi-channel dance!

  9. #84
    Junior Member
    Join Date
    Mar 2017
    Posts
    17
    Nice! Glad it worked. Thanks for helping me as well!

  10. #85
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,344
    Yes, the TDM input needs 16 memory just to have buffers to store the incoming data, then you need more on top of that just to do anything.

    In the documentation, I put this note at the bottom:

    AudioMemory should be at least 16. Even if most channels are unused, this TDM object will need to allocate 16 blocks of memory.
    Maybe it should be worded differently? Or moved up a bit where it's more visible?

  11. #86
    Paul,

    All good, I saw that and so I was always using 30, which I thought would be plenty, but wasn't. It was my fault, should have thought of that, pretty obvious thing to try.

  12. #87
    Junior Member
    Join Date
    Mar 2016
    Posts
    5
    Hi. Is CS42448 board work with Teensy 3.6?

  13. #88
    Junior Member
    Join Date
    Feb 2018
    Posts
    1
    Hello! Does anyone have an extra PCB lying around they'd be willing to sell me? This seems perfect for a few projects I'm working on.

  14. #89
    Junior Member
    Join Date
    Mar 2015
    Posts
    9
    Hi everyone!
    My question is concerning the CS42448 board and it might be a bit silly...sorry.
    I'm having an hard time to understand how to patch the CS42448 ins and outs and how to use the TDM.

    I can't understand were i should plug my end of chain signal on the TDM object, do i need an extra I2S object?
    Let's say i want to output a mixer signal on output channel 1...

    is there a simple example code for this?

    Thanks!

  15. #90
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,344
    Quote Originally Posted by manatee View Post
    I can't understand were i should plug my end of chain signal on the TDM object,
    Let's say i want to output a mixer signal on output channel 1...
    Do it like this:

    Click image for larger version. 

Name:	sc.png 
Views:	36 
Size:	16.4 KB 
ID:	14108

    do i need an extra I2S object?
    No, do not use any I2S objects! Use only the TDM ones if you're doing TDM protocol!

  16. #91
    hello all! sorry to resurrect a slightly old thread. I have a hardware question about the CS42448. I've been learning electronics thanks to teensy 3.6 and have been building myself eurorack modules. I'm up to iteration 4 - the first 3 used SPI multichannel DACs/ADCs, and various other bits, and I had great fun persuading the teensy to push 32 channels of audio through two SPI buses at 32khz. (16 in and 16 out). however I decided to do a 'simplified' build based on TDM, and came across Paul's great project and this thread.

    for context here's my schematic - you can ignore most of it except the codec in the middle, above the teensy. https://www.dropbox.com/s/wbt0lgbv3e...minii.pdf?dl=0

    my question is - I can't get any audio out of the AOUT pins! I'm basing the TDM-related teensy pins directly on paul's post upthread where he specifies pins used on his oshpark board; the analog side of my board is different, in that I'm trying to do active in/out (to hit eurorack levels) with differential opamps, but the tdm bit and the software init is a direct crib from Audio lib and this thread. (thanks!) I can see power in all the right places, I can see a steady bit-wide 44.1khz on LRCLK (teensy pin 23), 22mhz on MCLK (pin 11) and 11mhz on BCLK (pin 9). TX and RX are full of nice looking data, but if I fill the DMA buffers with sines, saws, or white noise - I see it on the TX pin, but nothing comes out of the dac. I can read and write registers over i2c, and it seems to work even tho I tied the 2 i2c address pins hard to ground instead of thru a resistor (oops!), and they read back as I write them; I can see data on TX (teensy pin 22) and I even see data coming back from the codec on RX - tho the analog inputs are floating (opamps not populated yet) in my build at the mo.

    but the outputs stay stubbornly fixed at around VQ, which is *meant* to be 0.5xVA (=2.5v for me), but actually sits at 1.25v (the most suspicious thing. but why?). So, its as if the outputs are muted or seeing no data, with the added twist that VQ is not at the level the datasheet says it should be at.

    I'm fairly new to electronics so I'm stumped how to debug further. anyone got any ideas? I deviated in one way from Paul's pin spec - he said he tied the AUX clock pins (20, 21 on the CS) to ground, but they are listed as outputs on the datasheet so I left them NC; I also left mutec (an output?) NC, as you can see from my schematic.

    my only next thought is to build up a new board, without the output opamps - just a codec, filter caps and a teensy - to see if maybe my active output circuit is loading them or shorting them in some silly way? seems unlikely but I'm lost!

    thanks again to this lovely community in which i've now been lurking read-only for 6 months. teensy has been a great introduction to electronics!

  17. #92
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,344
    Looks like you have 25K resistors connected to the AOUT pins, so I wouldn't imaging you're loading too heavily!

    I'd look at things like the reset signal and whether you've running acks when configuring it by I2C.

    Worst case, you could always order that board from OSH Park and solder one up. I built 2 of them and gave the 3rd bare board away. The 2 I made definitely did work.

    When you do get this running, I hope you'll share photos and info. Quite a few people have talked about using this chip for synth projects... which is the reason I went to the trouble of making that test board and writing the TDM code. So far I don't believe I've actually seen any finished synth modules actually using it. Would love to show one on the website blog.

  18. #93
    thanks paul! I think reset is a good shout; I'm on vacation now, but plan to check reset when I get back - it's another difference from your board, where you use the dedicated reset chip. I plan to try pulling reset down so that when the teensy boots (I assume all pins are hi-z?) the codec sees a consistent 'reset asserted' signal until I set it output and high in software.

    after I posted I found that if I short VQ to 5V briefly (I did it by accident by bridging two pins with a probe!) the entire circuit springs to life perfectly - so I'm close! VQ stops 'sagging', and settles at the correct voltage, after which the outputs un-mute. I suspected a solder bridge or dry joint as I'm new to SMD soldering, (I am no goddess...) but after touchup the problem stubbornly persists. as well as trying the reset pulldown, I've ordered a cheap oven and am going to try making a second copy to learn home reflow; perhaps that one will not exhibit the problem. last resort will be dead-bugging a little transistor onto VQ and get the teensy to short it to life!

    I haven't used I2C before. I'm using the default Wire library; what do you mean by 'running acks'?

    Happy to share pictures when done! if anyone reading is interested, you can follow my entire journey from buying a soldering iron, stumbling on teensy, building my first modular kits (I'm new to eurorack too) and building (now) 4 revs here - twitter.com/mmalex/media - dating back to feb 2018.
    here's a previous rev: https://twitter.com/mmalex/status/1001941811424833536
    it was quite fancy - it had two 8 channel AD5668 DACs, an 8 channel ADC by TI (I forget the number!), and 3x microchip megabit SPI ram, all running on SPI0; then some shift registers on SPI1 to run an 8x32 led matrix display, 8 multiplexed encoders, buttons, and RGB leds via a 4051, and 16 extra analog inputs thru a dual 8 channel analog switch to the two teensy 3.6 ADCs. the idea was to use the SPI dacs/adcs for audio rate stuff, and the teensy for CV up to about 1khz. I ran a master 32khz timer interrupt on the teensy, (which worked flawlessly from day 1, btw! I used it as my 'known baseline' whenever anything went wrong. so great) - which filled in a single sample's worth of outputs and inputs and RAM reads/writes, and kicked the DMA to SPI0, before running the audio rate DSP code and updating the multiplexers and kicking the teensy ADC on alternate 'ticks'; the 'main' (non interrupt) code updated the display over SPI1. it worked quite well, but there was some jitter that led to audio distortion and the lack of decent filtering on both in and out led the quality to be less than I had hoped.

    the new build is much simpler - I've moved to an OLED SPI display (but one without a noisy boost converter! avoid the adafruit ones for audio work unless you have really good power supply) - and the TDM chip for most ins/outs. the teensy DAC provides the last 2 outs, and teensy ADC gives me 4 ins for a total of 10 in 10 out.
    https://twitter.com/mmalex/status/1020789031624429569

    when I'm back from vacation, I'll let you know what I find with the reset pin, and the reflow build! thanks again.

  19. #94
    (sorry one other software thing in case it helps anyone - I found that it works really well to set up 4-byte DMA transfers to PUSHR, because then you can have it toggle the 5 CS lines to control multiple devices in a single DMA burst. it doubles the size of the dma transfer, but is what made it possible for me to efficiently run so many SPI devices without CPU intervention. the DMASPI lib and base DMA libs were very helpful 'cribsheets' to figure out the right register settings. thanks to the authors!)

  20. #95
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,344
    Opps, "returning" acks. Been trying to catch up to forum questions these last few days... typing fast and probably making tons of typos!

    The I2C protocol has an ack bit for every byte, so you can know if the other side really is working. In the audio lib CS42448 enable() function, I made it return a boolean. You get true returned only if the chip properly responded to every byte.

    Code:
    bool AudioControlCS42448::enable(void)
    {
            Wire.begin();
            // TODO: wait for reset signal high??
            if (!write(CS42448_Power_Control, 0xFF)) return false; // power down
            if (!write(CS42448_Functional_Mode, default_config, sizeof(default_config))) return false;
            if (!write(CS42448_Power_Control, 0)) return false; // power up
            return true;
    }
    So the first very easy thing, if you're not already doing it, is check whether enable is returning true or false when your code tries to initialize the CS42448.

    But with the VQ discovery, it does indeed sound like you're close to finding a "simple" hardware problem.


    Happy to share pictures when done! if anyone reading is interested, you can follow my entire journey from buying a soldering iron, stumbling on teensy, building my first modular kits (I'm new to eurorack too) and building (now) 4 revs here - twitter.com/mmalex/media - dating back to feb 2018.
    here's a previous rev: https://twitter.com/mmalex/status/1001941811424833536
    Wow, so many signals. But what does it actually *do* in a modular synth system? (or will do some day....)


    On the fine pitch soldering, I highly recommend using Kester 2331 liquid flux and Kester 331 lead-based solder (if you can even get this stuff in Europe...)

  21. #96
    Quote Originally Posted by PaulStoffregen View Post
    The I2C protocol has an ack bit for every byte, so you can know if the other side really is working.
    Ah, I see! yes, I am checking the return value (and Serial.println-ing if fail) - and all looks good. I also implemented a 'read registers back' per data sheet, and they take on whatever values I write.

    Quote Originally Posted by PaulStoffregen View Post
    But with the VQ discovery, it does indeed sound like you're close to finding a "simple" hardware problem.
    I hope so! I was surprised when I touched it up and it didnt change I should invest in a proper iron too, I have a non-heat regulated one (no station), old flux and cheap chinese solder.

    Quote Originally Posted by PaulStoffregen View Post
    Wow, so many signals. But what does it actually *do* in a modular synth system? (or will do some day....)
    one day... it will basically be 5 configurable channels. so each could be an osc, an effect, or CV processor; or you could 'gang' them together if a particular algorithm needs more than 2-in-2-out. there's also global clock (tempo) in/out, and the 8 encoders allow a relatively shallow menu structure to allow some quite fancy software modulation, routing, randomization and sequencing of each paramter. so you can 'soft route' small % of any signal to any other signal, and every parameter has optional LFO, randomization and 8-step sequencing available within 2 clicks and a twist. DSP/software is my day-job though, so I am more interested in learning the build and the electronics side as the software grind will probably make it all feel a bit like work, albeit rewarding

    Quote Originally Posted by PaulStoffregen View Post
    On the fine pitch soldering, I highly recommend using Kester 2331 liquid flux and Kester 331 lead-based solder (if you can even get this stuff in Europe...)
    thanks! it does seem that kester is impossible to get over here, and mouser refuse to ship it to europe. odd, as we have many other fluxes and lead-ful things available. I'm definitely going to upgrade my soldering setup, anyway. thanks for the tips!

    as soon as I make any useful progress, I'll post more here (or in another thread if you think it would be more appropriate). if it works really well, I'll stick the design & software up online... but that's running, I haven't walked yet

  22. #97
    hi all! I know this is a teensy forum more than a related-hardware-peripheral forum, but since you've been so understanding and my experiments are germane to this thread, I thought I'd post a quick update.

    I wondered if it might be a construction defect or my dodgy soldering. so, I bought a toaster oven and tried reflow soldering for the first time, (I had a stencil made with my pcb) making a second 'copy' of my board. it was a super fun experience, and leads to a much nicer looking board. see https://twitter.com/mmalex/status/1027680837276450818

    sadly, it exhibits identical pathology. the only silver lining I can think of is that it somewhat reduces the chance it's a manufacturing defect, and more likely a design or software issue.

    basically, still sad I cant persuade my CS42448 to power up correctly, with VQ 'sagging' at 1.2v instead of 2.5v and the outputs muted. if I short VQ to 5v (I did this by accident the first time...) it springs to life. since I posted above, I've tried pulling the codec reset low via a 25k resistor (driven high later by teensy), to ensure reset is cleanly low on power up, and goes high only once; I've tried replacing my 0805 VQ capacitor with a bigger electrolytic; no change; and I've tried lots of combinations of boot sequence with random delays at various stages. all, no dice. I'm at a bit of an impasse; there's not much anyone can do remotely to help (unless by some miracle someone has seen this behaviour before) so I'm really just posting as a status update. I'll have another poke at the software once my enthusiasm ramps up a bit. there must be something wrong in my design, but it's beyond me perhaps power is not robust enough, or something.

    if there are any hardware debugging experts out there who know what their next move would be...

  23. #98
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,344
    If you're *really* stuck, maybe try ordering that board I published from OSH Park. It definitely works, so even if it's not ideal (and involves the cost of a 2nd set of parts), having a working board for comparison might help you get this problem sorted out.

  24. #99
    you're probably right tho I am terrified of it just working, which doesnt help explain why mine doesnt your audio lib fails to init my board also, (though I'm gonna re-double check) which makes me think it's a hardware issue, not a software one; so I'm not sure how I could A/B test the (let's assume!) working OSHPark board with my broken one. still, I have little excuse not to order one will do so shortly.

  25. #100
    I just tried using the audio lib; (Im not familiar with it), using this code in main.cpp (I'm using a makefile rather than arduino):
    Code:
    AudioInputTDM inputs;
    AudioSynthWaveform    waveform1;
    	AudioOutputTDM i2s1;
    	AudioConnection       patchCord1(waveform1, 0, i2s1, 0);
    	AudioConnection       patchCord2(waveform1, 0, i2s1, 1);
    AudioConnection       patchCord3(waveform1, 0, i2s1, 2);
    	AudioConnection       patchCord4(waveform1, 0, i2s1, 3);
    AudioConnection       patchCord5(waveform1, 0, i2s1, 4);
    	AudioConnection       patchCord6(waveform1, 0, i2s1, 5);
    AudioConnection       patchCord7(waveform1, 0, i2s1, 6);
    	AudioConnection       patchCord8(waveform1, 0, i2s1, 7);
    	AudioControlCS42448 cs;
    
    
    extern "C" int main(void)
    {
    	const static int RESETPIN=0;
    	pinMode(RESETPIN,OUTPUT);
    	digitalWriteFast(RESETPIN, 1);
    	AudioMemory(32);
    	i2s1.begin();
    	cs.enable();
    	cs.volume(1.f);
    	 waveform1.begin(WAVEFORM_SINE);
    	 waveform1.frequency(440);
      	waveform1.amplitude(0.9);
      	while(1);
    }
    from which I can coax no output at all! spot the audiolib noob mistake, perhaps. but if I hack memcpy_tdm_tx to put a sawtooth in 'procedurally', I get the same behaviour as described before - it shows up only after shorting VQ to 5v.

Posting Permissions

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