cores
cores copied to clipboard
PaulStoffregen
make audio buffer pool DMA friendly
This pull request is based on this Teensy discussion thread: https://forum.pjrc.com/threads/58234-Teensy-4-0-problem-with-DMA-to-from-OCRAM-interacting-with-Audio-library Please note it also requires a simple change to effecdt_freeverb.cpp. The #ifdef chain tyring to initialize the 'zeroBlock' of audio needs to be replaced with simple, size portable way to create the zero block.
// In effect_freeverb.cpp // Initialize the contents of the audio control block to zero as a temporary compile fix // If the solution is accepted in principle, before merging I can work on a more permanent // solution in freevery to zero both the control block and the data block. static const audio_block_t zeroblock = {0};
I'm happy to use this as a starting point to other better solutions. The end goal is simply get the audio_block_t data buffers to be on cache aligned boundaries.
+1, support from me. And I found no negative impact, absolutely nothing.
Why not replace the int16_t* pointer with void * ? This would allow easy allocations with other data types. The predefined AudioMemory macro could use int16_t. User could then easily copy code to setup and modify accordingly.
@WMXZ-EU I think that's a great idea to make the data pointer more abstract and not hard-coded to particular type. Lots of people want 24-bit or 32-bit float audio. There is often a requirement to know the size of an audio buffer in bytes, which a void * doesn't help with. sizeof(void) won't work of course. Even if the library doesn't support the types now, building an abstract interface now makes future changes more likely to be backwards compatible.
I could have an abstract type with a concrete definition:
#ifdef AUDIO_USE_INT16
typedef int16_t audio_sample_t; // this
#elif AUDIO_USE_FLOAT
typedef float audio_sample_t; // or this
// .. etc
...but how do I allow easy compile time configuration? I could wrap in some #ifdef but there is no easy way to inject compile time defines with the Arduino IDE system that I've found.
Any ideas on how we can easily both abstract and support multiple types for the audio sample?
@Blackaddr In order to know size of audio object data one could simply query sizeof(dataBuffers[0]), where visible, right? One should differentiate functionality in cores or in audio-library. cores should be flexible. audio-library can be specific. So, the only two functions on AudioStream that need the size of data are InitializeMemory and ReceiveWritable(..). This can be solved if in addition to the pointer to data buffer InitializeMemory should get the word size as parameter.
In record_sgtl5000 on my GitHub I went one step further and store word size in data_block.
At this point, I suspect it will be hard enough to convince Paul to accept this pull request even with it's singular goal of making the audio buffers DMA compatible. Adding additional features will make it less likely the PR will be accepted. I think further changes to the audio library to abstract the sample type are a great idea but should probably be done separately in another pull request.
Just a quick comment, to let you know I'm considering this. But I'm going to start 1.52 beta1 without it. I want to spend some time testing and benchmarking this, but I really need to get 1.52 started now. Please feel free to bring it up on the forum thread about 1.52-beta1 to remind me. ;)
Sorry Frank, can't do anything right now. PJRC is down to just Robin & me and we're crazy busy trying to do all the stuff our hourly employees (who are at home due to coronavirus caution) plus all the things we normally do.
Sorry Frank, can't do anything right now. PJRC is down to just Robin & me and we're crazy busy trying to do all the stuff our hourly employees (who are at home due to coronavirus caution) plus all the things we normally do.
No problem with delays here, Paul. Focus on keeping Robin, yourself and your business safe.