I forgot, you already pointed out a suspicious section of the code. I’ll look into it over the weekend, and I’m sure I’ll also find some time to fix the spelling error. 😅
I’d think 64-poly is a bit of a stretch, but you never know until you try! I’ve benchmarked up to 16 open files at once, and with a reasonable read size (chunks of 4kB at a time) and a decent SD card, like a fast SanDisk, you can get around...
There’s a chunk of this thread starting here which worked out OK for effectively doing a preload using existing library capabilities.
In essence, you set the playback speed to 0.0, play the file, then when you’re ready for audio to start, change...
I just knew you'd be on top of the feedback mechanism!
I have a suspicion that the issue with small block sizes is not the block count in the ring buffer, but that very small blocks are smaller than the USB packet sizes. Your block count...
Hi @alex6679. Yes, absolutely appreciate it's not an easy problem!
I think we're all pretty much agreeing with one another about (a) the clocks will never exactly match, and (b) there are issues with the stock implementation of asynchronous...
Well, knowing how the original code works is a benchmark, though any deep discussion might be better reserved for a thread of its own, rather than a thread that's specifically addressing improvements...
I agree, the IntervalTimer thing is a...
No it won’t. There are mechanisms in place to feed back the drift amount to the host, so it accommodates the mismatch in clock speeds. This is what Paul’s original code failed to do, and @alex6679 has managed to accomplish.
Any two clocks are...
OK, so in the Interests Of Science (or at least, vaguely reproducible results), I've done a bit of testing.
Teensy 4.0 or Teensy 3.2
Current "master" AudioStream sources, or alex6679's modified ones
slightly modified to toggle a pin on every...
I defer to @alex6679 for the fine detail, but I'm pretty sure it's the Teensy which dictates the sample rate, leaving the host to do any resampling required to match its internal clock. This is one of the major contributions he's made, getting...
Well, it’s better than the old Teensy 3.x which could only manage 44117.647Hz or so. The PIT has a 24MHz clock, which I think means the sample rate ends up being about 44100.547Hz. Of course, that means that AUDIO_SAMPLE_RATE_EXACT is not exact...
Recent versions (1.58 onwards) of Teensyduino spot the lack of an object with “update responsibility“ and put in an IntervalTimer to trigger updates.
Has the documentation been updated to match? Guess…
That's interesting - pity it seems to peter out without reaching a conclusion. I wonder if one might get better results using an I²S board which doesn't need MCLK?
Hmm ... looks like I must have worked from an old revision of the Reference Manual. Which might be why I was getting the occasional clicking, and the clock routing was removed from the Rev 3 manual
But then the Rev 3 change list has
I think I...
Thanks for testing. I think I should first fix it for Windows 11. I assume it will then also work for other operating systems.
I'll have a look at that.
Wow, that’s a blast from the past :D do let us all know if it works for you. I never did figure out why the SAI1 glitches when synced to S/PDIF… Maybe I should have another look.
Odd about the data sheet difference.
I've just been playing with the multi-channel USB code, since I know the stock audio library does not work with the reduced audio block size needed for low latency. As it stands right now it's not working with super-small blocks, but it appears...
Thanks for your input and tips. That's encouraging to hear.
Yes, I realize recording to SD is a finicky business, glad to know there's a solid library out there. I'll be sure to check it out.
The low latency setting for the PCM51xx chips is...
OK, input tested; 64-sample blocks work, 32 gives a sort of fizzing sound, 16 is silent. Just using the HardwareTesting/PassThroughUSB example, with the audio blocks bumped to 70, and selecting the Teensy as the PC's audio output. That was...
I didn’t test input, but I can later today.
I’ve taken another look, and am wondering if the way you deal with underflow might be the issue. If there isn’t enough audio data for the USB packet, everything gets dumped, whereas maybe the answer is...
That’s what the documentation states. 67cm cable length seems too long for high quality, though, since the cable doesn’t appear to be shielded.
I’d set the level as high as it will go without overloading the amp input. You can consult the data...
Yes. The headphone jack is only suitable for connecting headphones. Its “ground” connection is not a true ground but a virtual ground sitting at about 1.65V, and if accidentally connected to true ground may do anything from stopping working...
@alex6679, just a quick observation relating to another thread started where the user may want to use USB, and does state a low-latency requirement ...
I had a quick play with your latest updated code (knowing full well that the existing USB...
I just had a bit of a play. Reducing the block size to 16 samples I got the in-to-out latency down to about 1.3ms. I think just under half of that is down to the SGTL5000, so as noted you may get differing results with other hardware.
I also...
The stock audio library, using the PJRC Audio Adapter, has an in to out latency of about 6.4ms. I know this from measuring it myself. Obviously you’d need to reduce the audio block size to get to your desired latency, as you say, but 32 samples...
You could take a look at (the later pages of) this thread. Unfortunately it’s a bit hard to install as it stands, and previously suffered from a bunch of people who offered to help or did development, then didn’t follow through. However, the new...
The design intent of this branch was to preserve the original functionality, while adding abilities to bend pitch and get to lower notes. (There’s even a TODO comment in Paul’s original code about the latter.) A side-effect of bending the pitch...
Well, a couple of the commits after the old branch do mention better sustain and tuning, plus fixing an incorrect infinite low-level “sustain” due to loss of precision. So I would 100% recommend starting from those, or my new branch, which should...
OK, I've made some changes on a new branch you can find here.
As noted above, I've just added an optional weight parameter to setFeedbackLevel(). It defaults to 0.5f, but can be set between 0.0f and 1.0f. I believe the resulting code conforms...
That's interesting - I'll look out for it and see what can be done to keep the tuning accurate. Not intuitive why that occurs...
I'm working on this right now; currently I'm looking at making the method look like setFeedbackLevel(level, weight =...
That looks very promising, thanks. I’ll take a look / listen, and push an update if no serious issues become apparent. @kd5rxt-mark, if you’d be so kind as to stand ready to try it on TMPS, that would be great!
For backwards compatibility I...
I thought you just meant that I needed to rename things so I don't have name collisions with the older versions of those classes that exist in the audio library, in which case it wouldn't really matter whether I abide by official naming...
100% agree you need to keep the synth robust, and if having a bonkers amount of audio memory available is the price then so be it! There are other ways, like monitoring usage and refusing to play a note that would tip the system over the edge...
Wah? I meant your TaperedAudioSynthWaveform needed renaming...
There's no API call, because that's a poor way to implement pitch bend. There are two inputs to the AudioSynthKarplusStrongModulated object: you've clearly found the Drive one, the...
There are fundamental issues with accessing the SD card from your foreground code at the same time as using AudioPlaySdRaw, because the latter accesses the card from the Audio update interrupt. Sooner or later one access will interrupt the other...
It should work to check out your repo to libraries/Audio - I do it all the time. Switch on verbose compilation and check the build messages to ensure the IDE is picking up the correct path. If you adopt good version control practice and make a...
Hmmm ... still having problems here. I've updated the Pico code, but I'm finding the Teensy crashes if everything is plugged in at boot time, but not if booted with the hub only, and I add the Pico later. The logs are lightly annotated, plus...
Yep, Added 3 for a total of four. That did not fix the problem.
#include "USBHost_t36.h"
USBHost myusb;
USBHub hub1(myusb);
USBHub hub2(myusb);
USBSerial userial(myusb);
void setup()
{
pinMode(LED_BUILTIN, OUTPUT);
myusb.begin();
}
void...
I can confirm that something odd is going on. I added a few more USBHub objects to the Teensy code, as suggested by @KurtE in post #3, but the problem persists. I don't have a Pico 2W to hand, so this is with a first-gen Pico.
Some logs, with...
Neither function re-enables the previous IRQ state. And usb_serial_read() attempts to disable the IRQ while it fills the buffer, but then may call rx_queue_transfer() which enables it. At best, this is surely not as intended. At worst, it'll...
I've had a bit of a play, and a look at some documentation, and can't see anything to contradict the above - it can't be done [guaranteed properly].
As an immediate example where IRQ disabling appears to be done wrong, consider this edited...
I'm thinking about the likelihood of an ISR messing with an enable flag that doesn't belong to it. You just know users will do it ... like doing serial output from an ISR.
Or maybe we just leave that sort of user to the consequences of their...
But ... if you need to restore the NVIC IRQ enable flag to its previous state, you need to read it and then modify it ... and an interrupt could occur between those two accesses resulting in the read-back value being stale.
Most code fails to...
@jmarsh, based on your post #96 I tried to make an atomic NVIC_READ_DISABLE_IRQ(n) function. However, it's not behaving when used with an actual NVIC_ICERx register - the STREXW claims the store didn't occur, but in fact it did (which AFAIK is...
See links in post #13 above. A few people are using it, haven’t had any bug reports for ages so it seems stable enough. I’ll bring it in line with Teensyduino 1.60 if that ever gets released.