h4yn0nnym0u5e

Last week I tried to connect the Teensy's SPDIF output sinks to a cheap USB audio dongle (like this but from ebay and costing less than $10). It wouldn't pick up any sound, no matter if I used AudioOutputSPDIF, AudioOutputSPDIF2 or...

I’ll probably get bored soon :rolleyes: A lot of the motivation for that rig was getting fed up with disconnecting and reconnecting in order to try different displays, and the associated risk of damage to the kit. That looks like a nice...

Interesting findings! Looks very nice - awesome setup!

You really are leaving no stone unturned! Regarding the diode, the 3.5" ST7796 with the black PCB like I use does not have this diode so it may be a better option for anyone looking for this type of display, at least if they plan to hang...

So I've been down a rabbit hole trying to sort out multiple displays co-existing on a single SPI bus. Here we have ILI9341, GC9A01A, ST7735, ST7789 and ST7796 all running OK: The wiring is not pretty... ...and there turned out to be an issue...

Looking through the discussion, I noticed Paul's wishlist included multi-channel audio. My recent stackable 8x8 audio board (designed in response to the end of life of the CS42448) is open source for hardware and software. It uses the TLV320...

sounds good to me - cant wait to order a couple :) Thanks Ken - that is very generous of you, especially for the DIYers among us. Would normally go that route but soldering!!!

I am in the process of placing a production order, so I have some final pricing. ETA is not yet confirmed, but I don't think it will be very far out, probably sometime in August. I don't know if these parts will eventually become available...

I'd imagine it's worthwhile for some applications, maybe where larger RAM plus Flash would be useful and an SD card can't be used (e.g. high vibration environments). Also it's not a ridiculous cost, given the Teensy 4.1 is over $30, so by the...

First off, if you “just” want 16 channels of 16 bit audio, there are easier routes, e.g. this thread. 16 channels of 16-bit audio at 44.1kHz is 11.29Mbps. Teensy 4.x can do that, on the face of it. But … looking at the data sheet you can see...

Another thing that makes it tricky to keep things under control is that the Audio library provides the begin() method to start the hardware and DMA, and then spoils the whole thing by calling it from within the constructor… Similar criticisms...

…which I can confirm “works for me”, with a beneficial effect on the interaction between display SPI and Audio library DMA.

Is this any better? Dunno what went wrong there…

Don’t know how much this commit overlaps with your work - looks like less functionality. You may (or may not…) want to jump in.

Just done a quick test, and all appears to be well for my use case :) I've been able to remove the machinations with dma_channel_allocated_mask, and audio and async display updates continue to co-exist peacefully.

I've pushed some changes to my dmachannel_preempt branch. It was a force-push because I wanted to split the bugfix (fixing the 16 byte/8 byte transfer support) from the new enhancements. Changed the way new channels are allocated to prioritize...

Okay. The problem with loading samples seems to have been resolved. I no longer experienced crashes, even when quickly tapping the touchscreen. It seems to have only been related to the _bytesavailable variable. I deleted the lines for disabling...

Really? It doesn’t look much like it… …it looks like you still have a slightly modified copy of the original newdigate code. Which as I’ve repeatedly said, is not fit for serious use! The MicroDexed-touch code has an unloadSample method that...

So … what code is at 0xA09C? There’s a thread on the use of addr2line here, if you haven’t used it before. It’s still a TODO on the PJRC website…

Have you used CrashReport to try to find out where the crash is occurring? Does the synth have to be playing, or will it crash if you just keep loading different big samples? I just noticed your code in post #241 only stops playing after freeing...

Because of audiosample *sample = new audiosample(); you need to un-comment //delete Sample; or you will have a slow memory leak…

No, it just creates an instance of the loader. You only need, and ideally should only have, one such instance in your entire program. It attempts (rather poorly...) to keep track of the amount of PSRAM used, but each instance has its own count...

flashloader isn't very good - it has no way of freeing up unused samples. And your posted code fragment doesn't even attempt to address my point 2 in post #236...

Stop using the samples Free the PSRAM they’re in Allocate PSRAM for the new samples Load the samples into the allocated space

I updated with Paul's latest startup.cpp and FS.h in cores along with the LittleFS.cpp, LittleFS.h and LittleFS_NAND.cpp library files. My combined PSRAM and Flash test program that was hanging now runs OK with 16MB PSRAM and 2Gb NAND Flash...

Thanks for looking into this - definitely looks like it's been a bear to debug, and as you say quite likely an "undocumented feature".

Tested as mentioned in post #98, now with commit a78bc7c (cf. post #97). Still good. If I manage to find a new and exciting way of locking up at startup, I'll supply a copy by whatever means seems best at the time ... might be an issue, or on a...

Merged in your commit 2045f27, and tested with the new PSRAM/LittleFS sketch above, and another with TeensyDebug. Seems to be working. EDIT: posts crossed! Will try the new commit.

Thanks! calling the setLoopStart & setLoopFinish after play() solved that.

Thanks Paul. I pulled your LittleFS and cores changes, and started experiencing the startup hang again. Gah. Then I thought, well, if reset_PFD() is still the culprit, maybe it needs one of those magic ARM barrier instructions in it... Sure...

Glad it is working, Been a while since I pulled mine out of the cabinet. One of the early posting from 3 years ago, shows it running a version of the Uncanny eyes sketch, with two of the displays. Edit: Oops, I forgot to hit the post reply...

Was just catching up on the threads and glad you got it working - was going to say that as far as I remember it should work with a non-standard CS pin as long as it is a digital pin which Teeny 4.1 pins are that you would use.

It doesn’t by any chance also go away if you instead implement my PR#673, does it? I usually have it in place for using TeensyDebug. There’s definitely something odd happening in reset_PFD() - my recollection is I put a ‘scope on the Teensy, and...

Hmm, that's odd. Here's my test program: it still has the PSRAM_IDs array, which Paul has removed, so if you're using his version you'll have to delete those references. It may be worth your using my code for the time being, as the output could...

Right ... so this morning, everything's working fine ... no (deliberate) changes to anything! Weird, because even if it's dodgy wiring I would expect nothing to work, not just some of the tests. Anyway, confirmed that the library can indeed work...

Thanks @MichaelMeissner. So maybe what @KurtE is saying is that multiple “special” /CS pins aren’t a feature of Teensy 4.x, but that it’s not too important anyway because it’ll only make a few nanoseconds’ difference if a non-special (like 22) is...

Sorry - Teensy 4.1. Can you clarify that? At the moment I only have the one display, but the reason I’ve used 22 as /CS is that 6 and 10 are potentially used by the audio adaptor. One possible future test would have two displays.

Wrong place - you need to pull from https://github.com/h4yn0nnym0u5e/LittleFS/tree/feature/big-PSRAM. I’m one of those odd people who uses git as intended, by developing on branches and keeping main aligned with the upstream repo :)

Quick question - should I expect this to be working OK with non-default /CS? Having some problems with a display from AliExpress which looks like this one. The Google Translate of the Chinese silkscreen is ambiguous: "this module can not...

If you want a known-working TDM solution to get you going, take a look at this thread. Tindie link (which I can't immediately find on the thread) is https://www.tindie.com/products/palmerr223/teensy-8x8-audio-board/. A single board gives you 8...

The Teensy 4.x boards are ideal for this. Start at this page https://www.pjrc.com/teensy/td_libs_Audio.html, look at the Design Tool which is linked from it (and be sure to look at the Info pane at the right, which tells you what pins to use)...

Interesting. I have a couple of other display types just arrived, so if they react poorly I’ll soon know. The mid-transaction break does a lot of calls to setAddr(), which will usually only need the row addresses changing…

Pushed some more stuff to the branch. shamelessy stole part of an optimisation for setting the output area, though I did fix a problem, and also not implement part of it, as maybe it's an assumption that it'll always be followed by writing to...

When/if a higher quality audio board is in the design phase, you'll be on my short list of people to evaluate how well prototypes actually perform. And generally speaking, yes, I agree with your analysis. For a future board designed with these...

My assessment is this: The audio adaptor doesn't have a separate clean (linear regulator) on its digital supply and a properly separate analog ground, so it picks up digital hash from the T4 processor driectly from the 3V3 and GND pins (the T4...

This may or may not be adjacent to the issues that can be experienced with using the audio library alongside asynchronous display updates. You can find a thread here about a fork of the ST7735 library to support the ST7796, which I subsequently...

Thanks for engaging at all, given you have other interesting stuff going on! I haven't done detailed benchmarks, but I'm fairly confident that performance hits vary from minor to none, depending on your use case. The following estimates are...

Most functions are agnostic about the audio source (SD, array, etc.), as far as I know, though there may be exceptions - I didn't look too closely at anything other than SD (filesystem) playback. One thing I do know is that the various play()...

Is the audio issue actually raised somewhere other than this thread? In most (not all) cases, it's wishful thinking to expect Paul to see stuff and take action. The best we can do is to submit the necessary PRs, cross-referring as necessary, and...

Yes, that branch. I opened from github desktop and didn't note it linked to main branch not dev/big-screen-t4 Hopefully in the next Beta release Paul will see the Audio issue and take that updated ST7796 and the associated DA edit(s)