Hmm ... interesting. It sounds like the Teensy is re-booting 8 seconds after playing the sample, which suggests perhaps it's crashing. You could add the following into startup:
if (CrashReport)
{...
Well, I wouldn't be able to promise to achieve anything concrete, that's for sure! Also my availability is going to be a bit variable for a while, so ... maybe after that? I'm not really an application kinda guy, I like to get the low-level tools...
I'm a bit concerned about the 700% CPU load reported for coreaudiod, and also that it's consumed over 122 days of CPU time. That suggests it might at least be time for a reboot...
For those who are curious about Weiweiweiwear's problem: We had a long video call this afternoon/evening and tried to find out what the problem is. Unfortunately we were not successful yet. In the end we compared the original usb input with my...
Well I don't know about Indian file, or how the bash command monitor might handle it, but there are two commands, and you should run one, then when the prompt reappears, run the next one. Typing them both at the same prompt one after another is...
Can't really hear the Teensy audio output on the video. I'm curious as to what you have the headphone output plugged into ... it must not be grounded, there's a warning on the back of the PCB but still none on the PJRC web page.
A couple of other thoughts... I didn't comment on the choice of size and number of buffers; I think that's very much a case of fine-tuning when you have a working system, and are trying to explore the boundaries. Bigger buffers give you more...
So ... have a bunch of samples open and stopped at the start, then assign to a track and start when triggered? I think that works once, then when you recycle them there's no mechanism in the library to "seek to 0", and in any case that'd probably...
Sorry about the play_failed() thing ... that was left over after using it to halt the system when it was about to crash, and look at the stack and objects' states using TeensyDebug. Removed and pushed, but you can just comment it, as you've...
These are two separate commands, as shown in post # 202. The first clones the git repo into the current folder; the second then switches to the required branch. I generally clone directly into the libraries folder; I can either switch back to the...
Ah, OK, never sure who knows what around here!
You don't clone a branch, it has to be the whole repo, so something like
git clone https://github.com/h4yn0nnym0u5e/Audio.git, then
git switch feature/buffered-SD-audio-EvR
No, it's intended to...
It's not yet a Pull Request, just one of my many branches. But ... assuming you don't want to use git, you would:
download a ZIP of the branch:
extract the files:
giving you:
then rename it:
All being well, it will now be picked up...
You may need to re-start the Arduino IDE once you've downloaded the above link to your libraries - then the buffered examples should show in the "Examples from Custom Libraries" section:
I've just pushed an update on a new branch - would be very grateful to anyone who can spare the time to try it out. There should be no changes needed to any sketches you already have working and stable.
However, it's come to my notice that...
Haven't checked your video: don't think it was part of the original post, and in any case I don't do Instagram so no way of seeing it. To be honest, apart from confirming that you have an issue, it's unlikely that it would help resolve things...
Works for me, here, on Windows 10, with a version of your sketch from post #127 modified to initialise the CS42448 properly. I played back an 8-channel WAV file using GoldWave, and got the expected outputs. Your screenshot is very pretty, but the...
You're right, they could be done incrementally, though my feeling is that having only part of the changes will make things a bit unwieldy for anyone who wants to try them out. But that'd be Paul's call - so long as we cross-reference the PRs then...
Built and tried it, it works for me, both files play repeatedly as intended. The files themselves are fine. Only differences from your setup are I've used a Teensy 4.1, but I left the code as-is and put the files on the audio adaptor SD card, so...
No, so far neither of those are even at the PR stage, let alone being in a TD 1.60 beta.
The multi-channel USB is quite complex, and will require synced PRs for both cores and Audio, plus ideally some buy-in from Paul to add options to the...
You didn't actually attach the audio (you may have to zip it as WAV isn't an allowed attachment type). The exact format is often a cause of issues, though as you're reporting the file plays once I'd be a bit surprised if that's the case here...
The difference being, the "dark magic" does actually have some documentation: the Design Tool gives you information when you select an object. It is usually helpful and rarely inaccurate, though it can be a bit out of date. The Audio library page...
Yes I was looking at your thread and have been tinkering around, thank you!
Sorry for derailing the thread a bit. I will try to use this soon and report back, very much appreciated.
Back on topic, I've done, tested and documented an update which doesn't require modifications to other libraries, and gives you a couple of options. You can find it on this branch. Note the markdown file for documentation.
Briefly, you can...
Struggling to respond here due to the DoS attack, I assume. But looks like @Rezo knows more about it than I do anyway :). The libraries have WAV header parsers of variable quality which you might be able to make use of, otherwise they probably...
Are you also still using my modified SdFat library? I think if you stop using it, even if you check for the card being busy, there's a risk of a crash.
Unfortunately it's a pretty knotty problem, exacerbated by my use of EventResponder to trigger SD reads. You've participated in The Other Thread on this matter :)
I'm not 100% convinced that checking for SD not being busy will be effective...
For a mono 16-bit WAV file at 44.1kHz sampling rate, you need 88200 bytes/s sustained rate. My vague rule of thumb for a decent SD card reading multiple files in fairly large chunks (say 8kB) is 10MB/s, so you can get quite a lot playing at once...
Sounds good, glad it's working OK for you. Yes, if you turn the above approach into a class then you should be able to instantiate multiple copies, each of which can be in a different state / stage of its progress. If it's worth the effort...
However … there is a flag to prevent yield() from running EventResponder. It’s probably not intended for libraries to use directly, and blocking all response execution is definitely overkill, like putting in a critical section when there’s only...
As noted by @shawn, you’ve edited what I said in a slightly misleading manner. I did think that, I now know better…
I think the way to think of it is that user code is running in an ISR, and yield() acts as the ISR return. The EventResponder...
Sure no problem. I know a piece of code is canonical, but there are a lot of moving parts so I'll try in words to begin with:
EventResponder hook set up to read audio data from SD card when triggered
audio library update() [interrupt] triggers...
Sorry, forgot I was going to add this to my response...
As noted, I can't do any safety checks - I don't have the information available at the point my hook code is called, with the system as-is.
And ... I don't see how EventResponder can be...
Of course. But if multiple external devices use a single SPI peripheral via libraries which deeply embed the peripheral access, how do you propose to keep those from tripping over one another? If one yields, and does not provide information that...
I would prefer that they didn't have to do that, because to my mind using an EventResponder instance to hide SomeLibrary's requirement for regular polling is very elegant. Any extra thing the user should do, but can forget, inevitably means that...
I've used EventResponder to good effect for decoupling the audio update loop from less deterministic data sources or sinks. In my case it's filesystems, which can be a bit slow but always respond eventually. For Ethernet audio the situation is...
This is all great, and kudos as ever to @shawn for being a responsive library maintainer who works with "his" users to provide an incredibly high level of support for all abilities.
For users at the level of @joepasquariello, who are prepared...
Hmmm ... that's a good thought. It's not really written such that derived classes can make much use of its methods, but it's certainly a concept worth toying with. At least it would provide a workaround for my use case - if people want SD access...
To record to the Teensy SD card the output of the audio engine exactly as sent to USB and/or audio adaptor, I made an example in my buffered SD play/record branch.
On the other hand, if you're wanting to send to the PC via USB, then the Teensy...
No, that is immediate, as it says. Not sure what the intent was for that, apart from testing before switching to one of the other deferred execution types.
Maybe a useful extension to EventResponder would be attachOnDemand(), and EventResponder::runOnDemand(). A function attached in "on demand" mode would be triggered as normal (e.g. within an interrupt), but only executed when the user's sketch...
Personally, I'd have a preference for a PCBA with just the surface-mount components fitted. That gives a bit of freedom with the connectors, though in all honesty it'd be most likely to get tested and then put in the toy box for "future...
Well ... it's "a" solution. Possibly even the right one, in the end. But there must be some reason Paul wrote EventResponder :)
There you go ... that's two of us at it now!
Yes, that would be the correct way to do it. There's still the issue...
OK, that’s good news. Let me know how it goes tweaking the settings, and if you can’t find a sweet spot please do post another example. I’ve got it hooked up to the ’scope for now, so looking at delays and timings is fairly easy.