h4yn0nnym0u5e

The Free Software Foundation? See this documentation, and specifically the last sentence:

SD::open() doesn’t take a set of bitwise flags for its second parameter, it takes one of three “mode” values: FILE_READ, FILE_WRITE or FILE_WRITE_BEGIN. This is of type uint8_t, hence the erroneous value 513 that you got from or’ing together...

You can use two to get 32MB: https://www.pjrc.com/category/news/

I was referring to your project when I said I can't find any repos... Thanks for this. I just merged the buffered-SD-audio-EvR branch into buffered-SD-for-PR. The EvR one was the latest and greatest, having a number of fixes which allow...

I can’t lay claim to the Audio library, it’s part of Teensyduino, and the work of many hands. The buffered SD playback, yes - and with luck that will be pulled into the official release some time… I did a quick search, and can’t find any...

Acknowledgements I want to extend my sincere gratitude to @PaulStoffregen, creator of the Teensy platform, for his guidance and valuable support throughout the development and testing of this project. His expertise and contributions to the...

Paragraphs exist for a purpose! A large block of text like that will put people off reading it.

Ever used a debugger with templated code? Or worse with STL classes? Heavy obfuscation is commonplace.

Hmm ... so if I want to write a method like bool initSAI(SAI& mySAI, SAImode_t mode) // mode is I2S, TDM, S/PDIF etc. { switch (mode) { case SAI_mode_I2S: mySAI.TCR1 = value for TCR1 mySAI.TCR2 = value for...

I’m definitely keeping it in mind as a useful resource. The thing is that most of my register-bashing use is modifying existing libraries, where adding another dependency is unlikely to be especially helpful. It’s hard enough as it is to get a...

I’m sorry, but … just no. If you’re happy doing bit shifts and masks in your head, that’s great. I’m not. The field names match the datasheet (which I agree you need to have to hand - no question). Using “readable” ones would just add a...

Either version requires you to have relevant page of the datasheet to understand - if your field names were readable then it would be better, but probably multi-line! Perhaps best to wrap all the register encoding in functions/macros with well...

Here's some test code: /************************************************************************** Teensy 4.1 basic DMA thrash test MicroDexed setup uses PCM5102; add a control object if your audio hardware requires it...

It’s almost certainly not… I’ve experienced DMA contention with audio, and it’s not just “annoying ticking”, it’s horribly garbled. This ticking is only really perceptible when all synth voices are silent, and is synchronised with the free memory...

Ok, thank you for the clarification. For the sake of completeness, here is a table showing output generation rates of FFT objects, in their original source codes, sorted by their result generation rates, from more frequent to less frequent...

OK, I've hacked together a test sketch which can compare the old and new FFTs. I'm fairly content that they produce identical results where possible (which I'm sure I would've tested, though I can't find the relevant code...). I can't compare the...

I think you're correct. I need to dig out / create a test sketch to make sure I've reproduced the output of the original code accurately, while making it more efficient ...

Maybe easier to write, but a complete pain to read o_O. Compare I2S0_TCR4 = I2S_TCR4_FRSZ(3) | I2S_TCR4_SYWD(0) | I2S_TCR4_MF | I2S_TCR4_FSP | I2S_TCR4_FSD; with I2S0_TCR4 = 0x00030013; I know which one I'd rather be confronted with. I've not...

The SGTL5000 datasheet I have (rev 7 from 2022) has this table:

I was sure that the branch that has the clipping of the Async I had merged it in, but does not appear to be: https://github.com/KurtE/ILI9341_t3n/tree/try_clipped_async It did not have the continuous updates support. It also also I believe...

…oh, I see … “audio” isn’t in the title. But the post is in the Audio section of the forum :)

Not for the ILI9341_t3n library, as far as I can tell. All the code and comments I can find suggest only full-screen updates are implemented. As I found out when updating the ST77xx library, an asynchronous change to a clip rectangle is actually...

Not that pushing it should really be necessary. 105MHz is about 52MB/s, but 16 stereo channels at 44.1kHz is only 2.8MB/s. Which is why streaming from SD card can work just fine, provided you’re careful how you go about it. Which I am…

Note that recently a 16MB PSRAM chip has become available, and the latest Teensyduino supports it, so 32MB is possible. Not sure how widely available they are. I’ve not used Flash much. AFAIK it’s mostly supported by LittleFS, and is OK if you...

That works, as long as you have PSRAM fitted (it wasn’t mentioned…), and as long as you don’t want to play more than 95 seconds of mono audio (do your own maths for stereo, or multiple simultaneous files), and you can tolerate the time taken to...

I know AI info is suspect when I see it quoting stuff I wrote ;~) The thread that @h4yn0nnym0u5e linked to has lots of good info buried in it about this issue. Rapidly drawing larger filled rectangles like for audio amplitude bars, tended to...

Yes, anything you can do to reduce the time taken for a single display change will help. Assuming a SPI bus speed of 16MHz, keeping operations to fewer than 1000 pixels will make them take less than 1ms, very roughly. To draw a large amplitude...

Yup, AI fails again... As noted by @jmarsh, not applicable since the SDIO slot is already in use ...so this isn't applicable either Not stated by OP, but almost certainly already true Entirely irrelevant, SD card streaming is not affected by...

The FIR filter requires an even number of coefficients. If you want a 5-tap filter, you need to set num_taps to 6, and append a zero value to intTaps[].

Good input. I will keep that in mind for the next updates.

For what it’s worth, I often find it very helpful to be able to follow development progress through successive minor changes, ideally on one or more branches that then get merged to trunk (or whatever your preferred name is). If a library change...

Yes, but as with most non-standard USB settings the Arduino IDE and Teensyduino add-on don’t make it easy. For my own purposes I’ve made a utility to add extra settings - the repo I’ve linked there can also build menu settings to allow you to...

That’s not really a different library - the ReadMe says it’s based on the terrible one you had trouble with before… There certainly need to be pull-ups! They aren’t optional. And if you want to get to 400kHz they really need to be about 2k2 with...

I imagine the const was just copypasta, but @jmarsh makes a good point which is often overlooked - EXTMEM and DMAMEM can’t be initialised at compile time. All you can do is define the space, then fill in some data at run time, e.g. from a file on...

You don’t say which FT6336U library you’re using, but I’m pretty sure I found it. It’s no wonder you’re having problems, as it’s appallingly badly written. I suspect this line is the cause of most of your woes - I’d suggest you comment it out to...

Question 6 - yes, the ARM processor essentially makes no distinction between memory areas, unlike older Arduino generations where you had to treat PROGMEM and RAM very differently. PROGMEM (Flash) and EXTMEM (PSRAM) run at very similar speeds...

Hmmm. On closer reading of the Hardware Initialisation section for the bootloader, it appears the “new Teensy” process still requires two physical steps - a short press on Program to load the safe copy of Blink, then the long press to copy it...

Been following these threads with interest, and a thing just occurred to me… The Teensy bootloader chip is just another processor, and presumably spends the vast majority of its life running a very dull state machine looking for activity on the...

Questions 1 and 2 - the answer is bound to be “it depends“. But 12-poly is possible with pretty complex topologies on an overclocked Teensy. Question 3 - a completely disconnected object is marked inactive and consumes negligible CPU time (just...

You probably need more CCs than just breath for a truly expressive sound; a reed or bite sensor for pitch bend is “traditional“, but an accelerometer is probably easier to implement and gives more channels to play with. Using modulated waveforms...

It’s super simple, just an unsigned 32-bit counter that increments on every CPU cycle (hence the CYCCNT). On Teensy 4.x at the default 600MHz it thus rolls over to zero about every 7 seconds. I really can’t think of anything else to say about it…

Looks like it does

I'm (nearly) seeing that, too. It's 14, rather than 15, and 500 in the next column rather than c0.

OK, so it's putting queue_buffer in RAM2, not EXTRAM (aka EXTMEM). Looking at the source, this seems correct, so not entirely sure if I have your current (troublesome) code. Forcing it into EXTRAM still works, yes.

OK, switched back to the released version of cores, and this is what I get: Memory Usage on Teensy 4.1: FLASH: code:103648, data:160952, headers:8804 free for files:7853060 RAM1: variables:282912, code:98600, padding:32472 free for local...

Any particular USB setting? I’m getting somewhat different memory sizes.

Yes - if you could shave >=296 bytes off the code or variables then you’d have low padding and more stack space. Then again, 110,304 should be easily enough for any sane application! If I recall correctly it was quite hard to nail down the point...

There were some startup issues fixed from 0.60.5 onwards which sound very much like this. They manifested as red LED blinks after flashing new code (8 could be the number…), but apparently minor changes could make them disappear … until they came...

I was commenting about the subassembly behind the glasses. The foreground wiring is still a mystery … four neat bundles but no clue as to their source or destination. It would reduce emissions and pickup, but I’d be a bit surprised if it made a...