Now for MP3 with FS...

@mjs513 - Just got back. Saw post #49 first... Yes MP3 play failed with original and both other changes to calloc(). The only change that worked was disabling 'configure_cache();' in startup.c. Will try your change and report...
 
@mjs513 - Just got back. Saw post #49 first... Yes MP3 play failed with original and both other changes to calloc(). The only change that worked was disabling 'configure_cache();' in startup.c. Will try your change and report...
 
@mjs513 - That's a big fat YES:) Took the time to make sure all of recent changes were put back to the original. Made the change you provided and it works. GOOD FIX:)
Def Lepard never sounded better:) Going let this run overnight...

Curious thought, could this be something that is plaguing MTP_Teensy?
 
@mjs513 - That's a big fat YES:) Took the time to make sure all of recent changes were put back to the original. Made the change you provided and it works. GOOD FIX:)
Def Lepard never sounded better:) Going let this run overnight...

Curious thought, could this be something that is plaguing MTP_Teensy?

Had same thought but didn't seem to help with large file transfers.
 
Ideas? Maybe not ;) Darts(Questions)? Maybe :D
...
I believe you said it works with static buffer instead?
If so have you tried the static buffer using DMAMEM? does it make a difference?
...
Sorry again dart board.
Note: that is why I asked about DMAMEM back in the dart board post...

@mjs513 - That's a big fat YES:) Took the time to make sure all of recent changes were put back to the original. Made the change you provided and it works. GOOD FIX:)
Def Lepard never sounded better:) Going let this run overnight...

Curious thought, could this be something that is plaguing MTP_Teensy?
Unfortunately this is not really a fix, but at least it helps localize the issue.

At this point I would doubt that this will change in the release code. As this has been bounced around since T4 beta time frame.

Like in the thread I started over two years ago, when I was battling a DMA issue, for example where a display object is created using new, and things like DMASettings contained in the object don't work.
https://forum.pjrc.com/threads/57326-T4-0-Memory-trying-to-make-sense-of-the-different-regions

Look toward the end of the first post for OCRAM...

As for MTP, I don't think so in the sense that both the Send and Receive functions, use things like:
Code:
static void rx_queue_transfer(int i)
{
	NVIC_DISABLE_IRQ(IRQ_USB1);
	void *buffer = rx_buffer + i * MTP_RX_SIZE_480;
	arm_dcache_delete(buffer, rx_packet_size);
	//memset(buffer, )
	usb_prepare_transfer(rx_transfer + i, buffer, rx_packet_size, i);
	NVIC_DISABLE_IRQ(IRQ_USB1);
	usb_receive(MTP_RX_ENDPOINT, rx_transfer + i);
	NVIC_ENABLE_IRQ(IRQ_USB1);
}
 
@wwatson - @KurtE
If interested here is the latest version the MTP_test_audio sketch.
 

Attachments

  • MTP_TEST_AUDIO.zip
    6 KB · Views: 42
Note the codecs just use "RAM".
They don't need to know if it is OCRAM, cached or whatever. It's just heap. Dumb RAM without any needed extras. Works with T3.2.

BUT: If the malloc fails or the codecs do not play, the whole heap management failed, because it's broken.
Why is it broken? Because of an cache issue (-> you said it works with cache disabled)

-> Which cache issue?
Well... good question. Normaly, this can happen if something goes wrong with the three core-cache functions.
Either because something (which *should* be 32Byte aligned (DMA)) is not 32Byte aligned , or because the 3 funcs are not called when they should be called.
Or, wrong usage of them. In the §$%& thread about these funcs, I gave examples what can happen to the heap, just by calling them. :) and showed that they can destroy the heap (and everything else)

Of course, a simple buffer-overflow can kill the heap, too.
But if it does not happen with disabled cache, something connected to it must be the reason.
Am I wrong?

Remember, the reason must be *outside* of the codecs. No need to look there.. they don't even know that they work on cached RAM and are not interested in this... ;)

So, just ask: *WHAT* uses the cache?

- USB
- AUDIO

What else?
 
Last edited:
Note the codecs just use "RAM".
They don't need to know if it is OCRAM, cached or whatever. It's just heap. Dumb RAM without any needed extras. Works with T3.2.

BUT: If the malloc fails or the codecs do not play, the whole heap management failed, because it's broken.
Why is it broken? Because of an cache issue (-> you said it works with cache disabled)

-> Which cache issue?
Well... good question. Normaly, this can happen if something goes wrong with the three core-cache functions.
Either because something (which *should* be 32Byte aligned (DMA)) is not 32Byte aligned , or because the 3 funcs are not called when they should be called.
Or, wrong usage of them. In the §$%& thread about these funcs, I gave examples what can happen to the heap, just by calling them. :) and showed that they can destroy the heap (and everything else)

Of yourse, a simple buffer-overflow can kill the heap, too.
But if it does not happen without cache, something connected to it must be the reason.
Am I wrong?

Ok I made one change to calloc that seemed to resolve playing MP3's for me without disabling cache. However when I first played a series of wav files and the next file was a AAC file it wouldn't play. But if the AAC file played first then no issue with wav file. MP3s still played regardless of order. If I disabled cache for the // RAM (AXI bus) region then the order of files didn't matter.

So there is some sort of conflict somewhere but there are alot of moving pieces here. Never really saw where anyone every played wav's plus mp3s + aac etc together. I did order a new Rev C board so I can test correctly on T3x's to see if the same problem exists - should have that today. Think probably should try playing all the files just using the SD Card without using LittleFS or USB just in case to try and isolate the problem further
 
I know late to the table...

But decided to at least set it up...
So with @mjs513s help was able to setup his test sketch and get rid of most of the warnings, except:
Code:
C:\Users\kurte\Documents\Arduino\libraries\Arduino-Teensy-Codec-lib\oggparse.cpp:323:39: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
       }while(pagehdr->granuleposition == -1 || pagehdr->granuleposition <= granulePos);
                                       ^

https://github.com/FrankBoesing/Arduino-Teensy-Codec-lib/blob/master/oggparse.cpp#L323

Where: pagehdr->granuleposition is an uint64_t
Not sure if this will cause any issues or not... I would assume it is a warning on esp32 as well?
 
I don't know now. I don't use opus on ESP - for Radio streams, AAC and MP3 are enough.
Opus was a user contribution some month ago.
I guess it's intended and that line seems to be by the Opus team. I did only a quick look.
Btw I have no Idea if Opus works on 3.x
 
So there is some sort of conflict somewhere but there are alot of moving pieces here.

If it works differently with cache than without - what reason is there that is not related to the cache?

I lack the imagination for this conclusion.
Say an example?
 
If it works differently with cache than without - what reason is there that is not related to the cache?

You are right that it is very likely to be related to the cache... But the question is how...

Example: Cache reads of stuff goes faster than without cache... Also maybe different on memory buss contentions...

Or maybe something simple like: maybe some function like: calloc
Which I don't think I have used for a very long time, has some specialty code in it for zero the memory, which does directly to the memory and bypasses the cache... And as such maybe when read things are not zero...

Or ???
 
Oh my... If you keep this up, you'll make me bring out the Teensy again :)... I hope I can hold off until the weekend...
My radio works very reliable now (playing 48k 256kbsp AAC stream without any glitch for 12 hrs now, stream is psram-buffered), but still on a blank screen and I still have to edit the sourcecode to change the station...

(The upper board is (c) Frank B. :) - next revision will have the parts on the backside - total height with cap touch 320*480 display .incl will then be like a Teensy with pins. And it will have a SD-Slot.
20211201_182301.png20211201_182316.png
 
Last edited:
@KurtE - @wwatson
I just forked @wwatson repository and added my changes along with an extras folder that contain a zip file for the changed play_sd_wav and play_sd_raw that go into the audio library so you can use FS objects. I also added an examples folder (mjs) for two WIP examples the first is the MTP_test_audio and a version that plays all from just a SD Card (No MTP/LFS needed) the updated version is here:

https://github.com/mjs513/Arduino-Teensy-Codec-lib

I think I found a way so not to have to change the cache so strange things don't happen with the AAC playing after wav/mp3's more in the next post.

EDIT: Only seems to work if AAC is played first then other files. So looks like nocache does work but have to figure where the issue is.
 
Last edited:
@Frank B - @KurtE - @wwatson
Going back through the T4 beta thread from long ago actually found where I tested the codec library the T4 beta board when I think it was still the 1052 chip not 100% sure though on that one. Anyway I posted to Frank that the library was working with the T4 and it was fixed (https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=199067&viewfull=1#post199067)
@mjs, i've fixed the codecs-library. should compile now
On T4, it uses IRQ_Reserved1 as secondary interrupt.
I actually tested the change and it all the formats worked with the SD Card: https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=199104&viewfull=1#post199104

In looking at the codecs.h file, currently I think the change was:
Code:
#define IRQ_AUDIO			IRQ_SOFTWARE	// see AudioStream.cpp

#if defined(__IMXRT1052__) &&  !defined(__IMXRT1062__)
#define IRQ_AUDIOCODEC		IRQ_Reserved1
#else
#define IRQ_AUDIOCODEC		55				// use a "reserved" (free) interrupt vector
#endif
if I change it to:
Code:
#define IRQ_AUDIO			IRQ_SOFTWARE	// see AudioStream.cpp

#if defined(__IMXRT1052__) ||  defined(__IMXRT1062__)
#define IRQ_AUDIOCODEC		IRQ_Reserved1
#else
#define IRQ_AUDIOCODEC		55				// use a "reserved" (free) interrupt vector
#endif
I can at least get the AAC file to play and playing a bunch of wav/mp3 files without change the cache configuration.

So don't know what changed from T4 beta testing days to now.
 
@mjs513 - Will download on my laptop and test/play. It will probably be this weekend before I can:( My curiosity is killing me:)
 
@MJS: Indeed, 55 is the BEE interrupt. Cab produce problems since there is encryption..
The reserved interrupt for T4 came later.

So, that change makes sense.
Can you do a PR, please?

(I can not test it now...)

I guiess i wrote it this way as a reminder, to edit it later, when Reserved1 is defined.. seems I forgot it :)
 
Last edited:
@MJS: Indeed, 55 is the BEE interrupt. Cab produce problems since there is encryption..
The reserved interrupt for T4 came later.

So, that change makes sense.
Can you do a PR, please?

(I can not test it now...)

I guiess i wrote it this way as a reminder, to edit it later, when Reserved1 is defined.. seems I forgot it :)

Seems like we all forgot :) Will do the PR but want to do a bit more debugging to see if we can figure out whats going on with FLAC but think that might be beyond me. Even with Cache turned off FLACs still don't play. But guess more to follow.
 
We were experimenting (@KurtE and I) a bit more with the MPT_test_audio sketch and think I isolated the issue down with having to use nocache for RAM(XIP) region only when using a USB Drive. Figured this one out when I added a few more MP3's to the mix.

Situation: I ripped a few youtube mp3's using audacity and when I tried to play them on the Jump Drive they wouldn't play but would play from the SD Card (I put these files in a separate directory). When I changed to nocache they would play from the USB as well. But still not sure what the root cause is.
 
Will have to play some more with this today and see if we can isolate...
When you say the would not play... Did the open fail or did they just not produce noise (oops I mean music ;) )
 
Will have to play some more with this today and see if we can isolate...
When you say the would not play... Did the open fail or did they just not produce noise (oops I mean music ;) )

Oops - should have said no noise coming from speak and file seems to open and close really fast before getting the file.
 
@KurtE - @wwatson - @Frank B

Finally got around to soldering up a Rev C audio shield to test a T3.6 with the changes and codecs:
1. SD Cards reads and plays all files without a problem except FLA files still produce no sound even though seems like it should be playing.
2. USB audio files on a jump drive all play without any issue. The issue I had with MP3s or AAC files playing are not seen on the T3.6. FLA files - still no joy.
 
@KurtE - @wwatson - @Frank B

Finally got around to soldering up a Rev C audio shield to test a T3.6 with the changes and codecs:
1. SD Cards reads and plays all files without a problem except FLA files still produce no sound even though seems like it should be playing.
2. USB audio files on a jump drive all play without any issue. The issue I had with MP3s or AAC files playing are not seen on the T3.6. FLA files - still no joy.

Try syncing up to my USBHost_t36 FS_Integration_MSC branch... I believe the AAC and MP3s are now working without changes to core.
 
Back
Top