h4yn0nnym0u5e

Yeah, so far so good, tried on a couple different Macs and it's all working perfectly!

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...

There's no code to initialise the CS42448 ... beyond that, I'm not a Mac user so it's hard to say more.

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...

Use the AudioRecordQueue object, probably. That's assuming you want something like an oscilloscope display.

Thought so. My fixes should remove the need for that ... I'm just creating some documentation: probably won't be done tonight, but soon...

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.

Nice! Timing sounds pretty good to my ear.

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...

Ah yes ... you do sometimes have to be a bit careful with Serial.print calls. A decent 'scope is very helpful, especially for timing-critical stuff.

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.

Could be. The trouble with a large sketch is that there are so many different ways it can go wrong, and it’s super hard for anyone else to review. You’re really reduced to putting in heap and stack monitors, plus anything else you can think of...

Yes, if you want to form a different connection using patchcord that’s already connected, you first have to disconnect it. As you’d created them in a disconnected state, there was no need to disconnect again. But it’s not an error and won’t cause...

Could you try this fix to the SdFat library? Install in your libraries folder as usual, it should mask the one provided by Teensyduino. I need to take a look at other filesystems - I think it's any SD access, but the author embedded a yield()...

OK, so I've just found a case where randomly sprinkling yield() calls around deeply-nested library code is a major pain for the application writer. I'm using EventResponder to re-fill audio buffers from SD card, without the user having to...

Gah. Something deep inside the SD library is calling yield(), and then failing to deal with the fallout of the fact that it's a weakly-defined function and could do anything. To quote Paul: "What yield() will actually do isn't a fixed known...

Hmmm ... just got round to trying it, and it's not working for me, either. Gotta get my investigating feet on...

I've just pushed a bug-fix to the multi-TDM branch. Please give this a go and see if it's working for you. I adapted my test setup from your posted code - the display stuff seemed irrelevant and I don't have one anyway, and I re-assigned some...

Bug-fix just pushed to the usual branch.

Same optimisation and CPU speed here. USB is set to Serial+MIDI, as it happens, but given that USB Audio isn't involved I can't see it's relevant. Bit of a mystery, this one. Sorry I can't help more ... if something occurs to me I'll be back :)

Nope, you can have many files open at once. That’s how the multi-file playback works, the file is open between play() and stop().

Haven't time at the moment for a full response, but one thing to avoid is opening and closing the file on every call to writeFileBufferedAsync(). That's likely to be very time consuming just on its own, and probably means that any tuning you try...

Can't find an issue here ... it's been running for over 30 minutes

It is definitely possible to patch an input straight to an output. Your code fragment should work, so the code you haven't posted must be causing the issue. Please ... if you have an issue, spend the time to craft and post a minimal complete...

40kB should be fine, though I'd always recommend instrumenting your code to see how much margin you have. Yes, it's easy to lose track of the fact that you somehow have to allow the buffering to take place. I quite like the following structure...

No worries. Might be a good idea to start a new thread, I guess. If you link to it from here then the assiduous reader will find it if they need it!