Search results

I had a play with this one (link to dev branch with a “better” implementation of yield()). It worked fine, but I didn’t explore deeply enough to find out whether the thread-naïve Teensy libraries cause serious issues.

Indeed. And I’ll reiterate, a huge amount of work has been done on improving the existing Teensyduino implementation, which you can find discussed and linked to in this thread. UAC2 is already done, up to 96k/8 channel/16bits has been tested and works, which is much closer to your desired rate...

You may want to take a look at this thread. I’ve had USB running at 96k/8 channels/16 bit, so it’s on the way. Barring hardware constraints for your codec, of course.

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 others and discussed here; that would probably...

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: this was also with Chrome - no issues with...

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 clocks. Is your AudioOutputADAT3 internally clocked...

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... Still need to do the other I²S stuff, and MQS...

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 software (which is where I come from, hence the...

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 table and a big lerpshift, Bad Things could happen...

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 0.5; if your old waveshape[] maps that to 0.75...

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 input goes away, I've bodged in a way for the I²S to...

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 predict what I'll want in the future, asking me now is...

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 PSRAM is the simplest way to go. With Teensyduino...

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 words; as far as I can see the ADC has no FIFO, so a...

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 humans, as we might confuse Rear for Right, but at...

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, and instrumenting usb_audio_transmit_callback(), I...

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 fairly standard cores, trying now with alex6679's...

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 noise". The most flexible way to do a level sweep is...

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 code? I²C addresses are 7 bits, not 16. Thirdly...

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 they'll reproduce the problem?

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 unavoidable no matter how you schedule SD writes...

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 frame packets. True, but this should (IMHO) be...

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 3.x setup, in particular the ~44117Hz sample rate...

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, because an int is 32 bits… You could edit the...

@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 made, but also a large number of issues and pull...

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 thing, so it’s hard to know what progress is being...

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 going on over the holiday :) 🍗🍾

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 internally, rather than just controlling an...

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/O. As it's an audio board I'd probably have gone...

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 Life intervened. We didn't use the Purepath Console...

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 #18, and noted that it's 14 years in the past! I...

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 simply request a re-schedule without causing a delay.

That table has invalid control values in it - anything above 0x7F would be interpreted as a command byte. However, the MIDI library prevents you sending those values, so your volume setting will actually send a value of 0x7F. I suggest you try using valid values, and see if you can get anything...

I suspect not. I'm guessing slightly here, but it appears that because FreeRTOS doesn't have a loop(), the yield and EventResponder::runFromInterrupt behaviour are emulated by creating two tasks. If you smash the record of the task handle, the task will still continue to run, and could be in...

I think you’re probably right, but it’s clearly causing issues when used with pre-emptive multitasking. The specific issue I had was with yield calls deep inside the SdFat library interacting with my EventResponder response functions … which called SD functions. It got very messy. The ones in...

As FreeRTOS has already overridden yield(), that’s not going to work, just cause a linker error… I’m not a big fan of all the yield calls buried in the various libraries. I believe the reasoning is that they ensure some (rather specific) set of polled items to execute during or after a...

I wonder if they're sanding the labelling off 1.8V parts? That would probably cause issues, which might take a while to show up. It doesn't really matter - I'd be contacting DigiKey for a refund, they really shouldn't be shipping sanded-off chips for any reason. I see DigiKey have just over...

But does the part actually have any marking on it? Do you have any more to check, since it seems the ones you’re testing have been repeatedly soldered and de-soldered? Your “basic connection test” only tells you about the status at boot time, which you’ve said tends to be OK unless the Teensy...

I've come back to this to see if I can make things work as expected. So far, I've failed miserably :mad: I've adapted the code from post #45 slightly (you have to do the pinMode() call first, then the Alt-mode to output the S/PDIF clock). I'm then using Paul's FreqCountMany modified slightly...

You haven't yet said which Teensyduino version you're using - this is quite important. Also, looking at your image of the parts you've fitted, the PSRAM part number is unreadable, so much so that it appears to have been deliberately removed. I would be highly suspicious about such a part, it...

For the 8MB parts, the datasheet says: For the ISSI 16MB parts, we're told: So the stress test needs to ensure that there are plenty of burst reads or writes which could cross the 1024-byte page boundaries. The original PSRAM test doesn't appear to trigger this, even with arbitrary-length...