h4yn0nnym0u5e

Additionally, while the specific context matters, I believe phases "version of Teensy" or "variant of Teensy" for products not from PJRC are extremely problematic.

I've been reluctant to write on this thread, because it really is about drama between Adafruit and SparkFun, or perhaps between Phil/Adafruit and a number people may or may not actually be connected to SparkFun. I have some strong feelings...

Surely this is very simple: "selectable as an option in unmodified Teensyduino". This leaves Paul in control of the brand and ecosystem that puts food on his table He could if so minded directly support one or other of the variants developed by...

With Windows 10 x64 I got: "More info" gives (note I renamed it as I was downloading it) "Run anyway" gave me a dialogue box I couldn't screenshot - "Do you want to allow this app to make changes?" "Yes" finally got to the installer: EDIT...

OK, fair enough. Do say if you have a specific routing in mind, but bear in mind I don’t have any ADAT kit so it’d be hard to test. Though if there’s a cheap interface you could recommend, I might spring for it.

No, it wasn't ideal! I'm guessing you're using the previous branch, which I've left intact while I break stuff on the new one. That probably doesn't have that issue, it's just when I try to flip back and forth between recovered and internal...

This covers some, but not all, of the changes I put in PR #790.

Bugfix update pushed: intermittent S/PDIF tends to cause weird PLL speeds (nothing to lock to), which in turn was resulting in an attempt to transmit NULL audio block pointers. This isn't trapped by the Audio library, and the Teensy crashes...

At this point, I would recommend both sides to just quit engaging. Go out and enjoy the coming weekend. Touch grass. Spend time with your family. Work on new cool projects (with a teensy!) Arguing the same point over and over is not changing...

That would work, too. I'm probably just paranoid about fragmentation, in most Teensy scenarios. But it's always possible, and impossible to prove that it can't happen, which is why you're only allowed statically allocated memory in medical...

Because heap fragmentation. But it is an alternative approach, though the calculation of lerpshift still needs to be in the same critical section, because if your new shape table is smaller than the old one, and you get an update() with a small...

In general, any call to an audio object method is fairly likely to cause a more or less audible “pop”, even if the underlying code is optimally written (which as you note, this isn’t). Say your incoming audio waveform has reached an amplitude of...

I agree this probably isn't productive for anyone, but for now I'm going to allow this thread to continue. However, I'm absolutely drawing the line at creating more duplicate threads promoting Adafruit's new competitive product or RP2350...

Do not create more threads to advertise RP2350 or products unrelated to Teensy.

OK, after a lot of distractions, I've done a bit of work on this and have a work-in-progress branch for consideration, if anyone's interested. As it turns out the fallback to the built-in clock doesn't appear to work as expected if the S/PDIF...

I don't have much useful to add to this thread, but since when did that stop anyone? ;) I tend to base my purchases on performance (for what I want, at the time) and price. Personality of the proprietor ... not so much. As I can't usually...

Indeed most other forums would have locked this thread. I'm not sure we've made the right decision, but for better or worse we're letting this play out as long as it stays mostly civil. Even more difficult (for me) has been resisting the urge...

No, but I probably could do so. Downside is I don’t have either an OctoWS2811 or new Ethernet kit, or 3D models I can drop into the CAD to wrap a box around…

Yes, that assessment of the relative memory speeds is broadly correct; there’s probably little difference between PSRAM and Flash, if both are fitted to the QPI pads on Teensy 4.1. If 16 samples of 1Mbyte is a definite upper limit then using 2x...

BITER/CITER are the major loop count; NBYTES is the minor loop count, and for some peripherals can be used to do more transfers without reloading the TCD. When messing with SPI transfers I found NBYTES was limited to the FIFO depth, i.e. 16...

Coming back to audio, Teensy is about the only platform that does multi-channel audio well. As I said earlier, my updated 8x8/16x16 audio board is open source hardware and software, and I'd be happy for Sparkfun to manufacture boards based on...

Thanks for that. Yes, I did take the trouble to download the USB spec just in case there was something helpful on the page (thanks for putting it in the comments, really helpful!). Clearly they didn't think it through. It's a bit ambiguous for...

Just given it a quick try, seems to be working well apart from generating a huge number of compile-time warnings due to a macro redefinition. I've submitted a PR to fix those. Setting the sample rate to Teensy 3.x emulation, i.e. 44117.64706Hz...

Ok, I’ve rewritten the function getTransmissionTarget(). I think it’s simpler now and shouldn’t run into integer overflow.

Seems to be working OK for me, at least for the last 40 minutes. macOS Tahoe 26.1, Intel MacBook Pro 16" 2019. Teensy is connected via a Dell dock and USB hub. Running a slightly modified Blink sketch, with Serial+MIDI+Audio; that was with a...

I messed about a bit, and if the static instance of usbMIDI is weakly defined, then the user code can define its own (strong) instance which invokes a different constructor. So something more consistent with the MIDI class would be possible.

How are you "doing a sweep"? Calling the amplitude() method inside loop() or something like that? Doing so will result in the level only changing on every audio update, i.e. every 2.9ms or so, which is very likely to result in audible "zipper...

Thanks for fixing that. Back then I only tested the common sampling frequencies. For now I merged your pull-request, but I hope that I'll soon find the time to refactor the function and to improve it. Shouldn't be too difficult. Unfortunately, I...

Yes. So it wouldn’t work, or at least would require some level of editing cores, which is not a useful approach. So the second-least-worst-thing would be to add a method which can switch off the automatic conversion, and document it.

Can't see anything very odd there, but I do have a few comments. First, when posting a block of code you're better off using </> button, not the inline >_ one. Second, what are you expecting when you have Wire.beginTransmission(0xb1ce); in your...

Probably. May be best to start a separate thread (which helps Future People find Relevant Stuff). When you post, a small example demonstrating the issue is always extremely helpful... I've got some tiny SSD1306 I²C OLEDs knocking about, if...

You haven't said, but is this the Teensy ADC? This seems to be a poor choice for high-quality audio ... as you're discovering. Even if you fix the clicks, it'll be subject to signifcant digital noise from the processor itself. This is true, and...

I agree. If I'm using a library, I typically do not want it to "lie" to me, especially where it's an external communication and real information is lost. The only exception would be something like a serial protocol which uses escape characters to...

I've treated myself to a fairly cheap 2019 MacBook Pro to play with this stuff - so far it seems to be behaving fine, though I haven't really pushed things to the limits as yet. One thing I have been doing is messing with emulating the Teensy...

That was the issue! Thanks!

You don’t need to call the I2S begin() methods. They’re called by the constructors, and doing so again may cause mayhem … not sure.

No need, maybe, but it would be good to have someone else test this, ideally the person whose problem it should fix.

Or, try installing a fixed version of the Keypad library. Please let us know if it works for you and I'll submit a pull request; it seems OK with my limited testing.

Looks like the ancient Keypad library is in serious need of a bit of maintenance. Even though you can apparently specify the number of rows, it actually only allows for ten rows of 16 columns. Except that it’s possibly 32 columns for Teensy...

@Michael Bachman, you're pretty much right, there's a distinct lack of new modules in the Audio library, though a fair amount of tweaking and bug-fixing has taken place. If you look at that repo you'll not only see that a lot of forks have been...

I don’t know where you’re looking, but this link shows more recent updates than that. Admittedly the release cycle is only when Teensyduino gets updated, which is glacially slow; and actually implementing version numbering is apparently not a...

Yes, that was my conclusion, too. Strange, because the datasheet appears to imply S/PDIF transmit will use the internal clock if the receive loses lock, without needing software reconfiguration. I'll get to it at some point, lots of family stuff...

You want this library, and this audio DAC is probably the smallest out there, followed by one of the widely available boards based on the PCM5102. You will need to completely re-write your code, because the Teensy will be doing all the playback...

In the spirit of using more modern C++ features instead of #defines, here’s another alternative: ModbusRTUClientClass& MB = ModbusRTUClient; // This is the same thing (spacing difference): ModbusRTUClientClass &MB = ModbusRTUClient; Or the more...

Just as a heads-up, there's some good support going on with this: see this issue and related development branch.

No, didn't try the filters, so no idea about the latency, and the data sheet doesn't seem to say anything about it. The GPxx pins can be set up to provide clock and receive data from PDM microphones, plus a bunch of other stuff including simple...

I did a bit of work on the TAC5212, courtesy of another forum member who may yet comment :) We got it working in TDM mode, and started getting the PDM mic inputs* working though not with 100% success. It's all gone a bit quiet - I think Real...

The reason for the issue with taskYIELD() is that it's actually a macro, not a function, hence you shouldn't put the scope resolution operator :: in front of it. Leaving it off fixes the compile error. I looked at the discussion linked in post...

You're right. The "!= NOT_STARTED" got me. Or change it to taskYield(), which does the same thing as taskDelay(0) and is more efficient, according to notes on the FreeRTOS site.

Err ... it definitely is! As written, the code will execute the vTaskDelay(1) if the scheduler is started, and the yield task is running, and yield wasn't called from within an interrupt. Try changing that line to vTaskDelay(0), which should...