Now for MP3 with FS...

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

2021-12-04 11_12_29-Window.png

Is there a case where it is not on the heap?
 
I hope the sectorBuffer is _always_ aligned? Otherwise it will crash the heap in other cases.
Would probably be needed to check this (and if the size is guraranteed to be a multiple of 32) with an assert().
 
Last edited:
Is it needed to flush it? If it gets overwritten anyway (by the read), an arm_dcache_delete() would be faster.
 
Is it needed to flush it? If it gets overwritten anyway (by the read), an arm_dcache_delete() would be faster.

..and I would porbably do this in queue_Data_Transfer() in ehci.cpp

Are writes not affected?? I guess yes.. so it would be needed for the other direction, too?
 
KurtE said:
Try syncing up to my USBHost_t36 FS_Integration_MSC branch... I believe the AAC and MP3s are now working without changes to core.

Just incorporated the change and seems to be working like a charm. Tested on a T4.1 without changing the RAM to NOCACHE using both 'P'lay All and 'p'lay single file

I've fixed FLAC (Tested with 3.6 only - T4 seems to be not reliable at the moment?)

https://github.com/FrankBoesing/Ard...mmit/576d62c4f15da3f80fc5b9ee14332bfae175ccf8

Frank - incorporated the change after Kurt's change and now playing FLAC files from USB, SD Card and Winbond 1G chip without any issues as well. Looks like everything is working again. Thank you. Sounds good too.
 
Please do not submit pull requests with GPLv3 code.

I want to be absolutely clear - this code will never be merged into the Teensy audio library because of Frank's choice to apply GPLv3.
 
Is it needed to flush it? If it gets overwritten anyway (by the read), an arm_dcache_delete() would be faster.

You are right, except that I don't think they are always properly aligned...
Did not run into this with other code may need to be updated at a low level... (I believe the code is in SDFat in either Fat or ExFat depending on what type of disk.
It was hit in:
Code:
size_t CodecFile::fillReadBuffer(File file, uint8_t *sd_buf, uint8_t *data, size_t dataLeft, size_t sd_bufsize)
{//TODO: Sync to 512-Byte blocks, if possible

	memmove(sd_buf, data, dataLeft);

	size_t spaceLeft = sd_bufsize - dataLeft;
	size_t read = dataLeft;
	size_t n;

	if (spaceLeft>0)
	{

		n = fread(sd_buf + dataLeft, spaceLeft);
		dataLeft += n;
...
In most cases with smaller reads, it will use the internal sector buffer to read in and cache a block and then copy out the piece you are asking for.

However in the case where lets say you ask to read > 512 bytes, the underlying code goes, it can bypass this and use your output buffer to read in multiple sectors at once and where
the target of the write is depends on of course where you are within your larger read, as it will first use whatever stuff is left in the current cache and then the output pointer to it
and then call of to read in one or more sectors directly...
 
Please do not submit pull requests with GPLv3 code.

I want to be absolutely clear - this code will never be merged into the Teensy audio library because of Frank's choice to apply GPLv3.

Paul,

I don't think that the @mjs513 PR to Audio has anything to do with Frank's work. It is simply to allow things like wave files to be played that are on other storage
than just SD cards. So for example can now play wave files that are stored on LittleFS storage or on MSC drives...

For me, the interesting thing with getting Frank's code to run, helped locate a hole in the MSC stuff on reading/writing blocks of data. As I mentioned in previous post the issue is that when we open up a file
and then try to do random reads, when you ask to read something > the sector size, the (Fat/ExFat) code will try to optimize and when possible call to read whole sectors into the target buffer. And if this
target buffer is lets say in DMAMEM it was not being arm_dcache_delete which caused us to not properly read in... And as I am not sure if the read buffer will be 32 byte aligned I am afraid to use the
simple delete version so use the flush_delete... Alternative method would be for a safe_arm_dcache_delete, which would check the first and last blocks to see if aligned to 32 bytes if not do the flush/delete operation
but for all of the others simply delete... Not sure in this case if that would speed things up or not...

Hope that makes sense.
 
@Paul, yup, this thread is about the aac/mp3/flac codecs - has nothing to do with "my" waveplayer.

I wouldn't merge the codecs to the offcial library. Although it works pretty good and stable since more than 7 years, it *still* uses the secondary interrupt trick which is not good PJRC-official library.
There was a little bug that I fixed now - it popped up now, because T4 now uses the BEE interrupt, which I used (was a bug..or, better, forgot to update it), and a minor flac issue.
And, it needs 30KB RAM, and flac way more..
 
Good Morning @all - Will reorient, update and do the PR's. Nice to see it's all working:) Had no doubt you guy's would figure it out:) I have a couple of things to do this morning first then...
 
@all - I have now been playing with the MMOD with Paul's break out board. Mainly because it has both USB and SDIO version of SD...

I tried running same program I run on T4.1... Which is a modified version of @mjs513

Works well on the USB...

BUT: SD with SDIO - not so good.
Sometimes it plays one note and ends, other times it plays one note and crashes.

Code:
 Space Used = 68780032
Filesystem Size = 32014073856
Directory
---------
mtpindex.dat                          0
System Volume Information/
  WPSettings.dat                      12
  IndexerVolumeGuid                   76
zarathustra.mp3                       489461
2001/
  calculations.wav                    426300
  completed.wav                       276460
  dangerous_to_remain.wav             372892
  enough_info.wav                     513388
  functional.wav                      237356
  one_moment.wav                      202236
  operational.wav                     772140
  sorry_dave.wav                      791164
  stop.wav                            200844
Audacity/
  Away_in_a_Manger.mp3                2014737
  Dont_Rain_on_My_Parade.mp3          3944449
  Take_My_Breathe_Away.mp3            5740819
  Welcome_Christmas.mp3               2985790
FLAC/
  T1_1024.FLA                         9802802
  T1_128.FLA                          11126659
  T1_256.FLA                          10415954
  T1_512.FLA                          10007370
Candyman.aac                          3177823
Dont Rain on My Parade.mp3            3944449
odd1.mp3                              46888
odd1.wav                              553004

Playing file: odd1.mp3
Playing(1) file: 'odd1.mp3'
User Abort
Done.
Playing file: 2001/stop.wav
Playing(2) file: '2001/stop.wav'
Audio Error: 1


*** Start Interval Timer ***
Date: 4 Dec 2021 7:31:29
The Start interval... is when program restarted... Does not show any Fault... May have to turn on my version of Core with full debug output and see if it shows something there
 
Update on MicroMod:

I turned on debug printing in Cores, startup a second T4 connected using the USB To Serial sketch..

Then rebuilt and sure enough it faulted. Note: I am using my own updates to core:
Code:
void unused_interrupt_vector(void)
{
	uint32_t i, ipsr, crc, count;
	const uint32_t *stack;
	struct arm_fault_info_struct *info;
	const uint32_t *p, *end;

	// disallow any nested interrupts
	__disable_irq();
	// store crash report info
	asm volatile("mrs %0, ipsr\n" : "=r" (ipsr) :: "memory");
	info = (struct arm_fault_info_struct *)0x2027FF80;
	info->ipsr = ipsr;
	asm volatile("mrs %0, msp\n" : "=r" (stack) :: "memory");

	info->cfsr = SCB_CFSR;
	info->hfsr = SCB_HFSR;
	info->mmfar = SCB_MMFAR;
	info->bfar = SCB_BFAR;
	info->ret = stack[6];
	info->xpsr = stack[7];
	info->temp = tempmonGetTemp();
	info->time = rtc_get();
	info->len = sizeof(*info) / 4;
	// add CRC to crash report
	crc = 0xFFFFFFFF;
	p = (uint32_t *)info;
	end = p + (sizeof(*info) / 4 - 1);
	while (p < end) {
		crc ^= *p++;
		for (i=0; i < 32; i++) crc = (crc >> 1) ^ (crc & 1)*0xEDB88320;
	}
	info->crc = crc;
	////////////////////////////////////////////////
	printf("\n >>>>> unused_interrupt_vector <<<<<\n");
    printf("  Code was executing from address 0x%x\n", info->ret);
    printf("  CFSR: %x\n", info->cfsr);
	if (((info->cfsr & (0x80)) >> 7) == 1) printf("\t(MMARVALID) Accessed Address: 0x%x\n", info->mmfar);
	printf("  XPSR: %x\n", info->xpsr);
    printf("  HFSR: %x\n", info->hfsr);
    printf("  STACK: %x\n", (uint32_t)stack);
    for (uint16_t i = 0; i < 32; i+=4) printf("\t %x %x %x %x\n", stack[-i],stack[-i-1], stack[-i-2],stack[-i-3]);
	////////////////////////////////////////////////
	arm_dcache_flush_delete(info, sizeof(*info));
...
The lines I added are between the ////// lines...

Sure enough it faulted:
Code:
 >>>>> unused_interrupt_vector <<<<<
  Code was executing from address 0x0000A1B2
  CFSR: 00000082
	(MMARVALID) Accessed Address: 0x200179E1
  XPSR: 010F0056
  HFSR: 00000000
  STACK: 20047E80
	 0000005D 00000000 0000000A 20047E80
	 2000AF24 0002DCA7 20047E80 2027FF80
	 20047E60 20047E84 2018101B 13110D0C
	 00000008 20047F48 00000049 00000000
	 00000000 20047EAC 00000001 000F4240
	 00000000 0000E731 00000000 00000001
	 20047E88 00000019 00000000 00000000
	 20047E88 20047F48 00000000 00000000
need to switch to alternate clock during reconfigure of ARM PLL
USB PLL is running, so we can use 120 MHz
Freq: 12 MHz * 66 / 4 / 1
ARM PLL=80002064
ARM PLL needs reconfigure
ARM PLL=80002042
New Frequency: ARM=198000000, IPG=99000000
Decreasing voltage to 1150 mV

and doing:
[CODE]
C:\Users\kurte\AppData\Local\Temp\arduino_build_MTP_TEST_AUDIO.ino>addr2line -e MTP_TEST_AUDIO.ino.elf 0x0000A1B2
C:\Users\kurte\Documents\Arduino\libraries\Audio/play_sd_wav.cpp:477

C:\Users\kurte\AppData\Local\Temp\arduino_build_MTP_TEST_AUDIO.ino>
***********IMXRT Startup**********[/CODE]
And in the case of my version of the sketch:
Code:
    case '\n':
    case 'h': menu(); break;
    }
    while (DBGSerial.read() != -1) ; // remove rest of characters.
  } else {
    #if USE_MSC == 1
    checkMSCChanges();
    #endif
    mtpd.loop();
  }
<THIS BLANK LINE IS LINE 477>
  if (write_data) {
    while (playMp31.isPlaying()) {
So probably stack was screwed up at that time...
 
@FrankB,@mjs513, @KurtE - Did the PR's. Before I did them I went through all the changes I made sure I normalized them. I took out the debug info I had put in. One thing I found was in play_sd_mp3.cpp. In the stop() function freeBuffer() was still commented out. Fixed that. Also when doing the pull request I got this warning:

Code:
x Can’t automatically merge. Don’t worry, you can still create the pull request.

It seems to be in oggparse.cpp:

Code:
<<<<<<< FS_Usage
      }while((int64_t) pagehdr->granuleposition == -1 || pagehdr->granuleposition <= granulePos);
=======
      }while((int64_t)pagehdr->granuleposition == -1 || pagehdr->granuleposition <= granulePos);
>>>>>>> master
Think it's just a missing space character before pagehdr.
I ran into one problem with my SSD. It was not initializing. Remembered I had that issue before. In msc.h the default timeout settings are to small.
Currently they are:
Code:
// These two defines are timeouts for detecting a connected drive
// and waiting for it to be operational.
#define MEDIA_READY_TIMEOUT	1000
#define MSC_CONNECT_TIMEOUT 4000
They should at least be:
Code:
// These two defines are timeouts for detecting a connected drive
// and waiting for it to be operational.
#define MEDIA_READY_TIMEOUT	5000
#define MSC_CONNECT_TIMEOUT 5000
I have a PR in for this.

Last issue I ran into was just a warning with MassStorageDriver.cpp:
Code:
/home/wwatson/arduino-1.8.16/hardware/teensy/avr/libraries/USBHost_t36-FS_Integration_MSC/src/MassStorageDriver.cpp: In member function 'uint8_t msController::msWriteBlocks(uint32_t, uint16_t, uint16_t, const void*)':
/home/wwatson/arduino-1.8.16/hardware/teensy/avr/libraries/USBHost_t36-FS_Integration_MSC/src/MassStorageDriver.cpp:672:109: warning: invalid conversion from 'const void*' to 'void*' [-fpermissive]
     if ((uint32_t)sectorBuffer >= 0x20200000u) arm_dcache_flush(sectorBuffer, (uint32_t)(Blocks * BlockSize));
                                                                                                             ^
In file included from /home/wwatson/arduino-1.8.16/hardware/teensy/avr/cores/teensy4/core_pins.h:32:0,
                 from /home/wwatson/arduino-1.8.16/hardware/teensy/avr/cores/teensy4/wiring.h:39,
                 from /home/wwatson/arduino-1.8.16/hardware/teensy/avr/cores/teensy4/WProgram.h:45,
                 from /tmp/arduino_build_646435/pch/Arduino.h:6:
/home/wwatson/arduino-1.8.16/hardware/teensy/avr/cores/teensy4/imxrt.h:9907:20: note:   initializing argument 1 of 'void arm_dcache_flush(void*, uint32_t)'
 static inline void arm_dcache_flush(void *addr, uint32_t size)

Just added a (void *) cast to:
Code:
arm_dcache_flush([COLOR="#FF0000"](void *)[/COLOR]sectorBuffer, (uint32_t)(Blocks * BlockSize));
In the "msReadBlocks()" and "msWriteBlocks()" functions. Hopefully that is correct:)

@all - Thanks for all the help with this:)
 
Note: I am going to take the MicroMod issue over to the integration thread as it is not really related...
 
@wwatson - @KurtE - @Frank B
Just catching up and just finished incorporating the changes in #90 so think I am now even.

Yes Frank - I always loved that Codec library and glad its now working with T4.1. Really does sound great especially with the Headset I picked up :)
 
@All - Just ran into a problem with playing wav files. If the file size is > ~60meg it will not play with recent changes to Audio library. Any thing less than 60meg and it plays. I have a 102meg wav file that plays with @FrankB's Teensy-WavePlayer I had originally modified it to play wav files with DiskIOMB. It worked with all wav file sizes. When I try to play the same files with the modified wav player files in the Audio library they will not play. I remember back when I first had it playing with MSC I had to increase the buffer size from 512 to 8192 to get it to play. Tried that and it still failed.

It's getting late and I I'm kinda burnt out. Been messing with this all day. I also saw similar issues on the other thread. More tommorow...
 
@All - Just ran into a problem with playing wav files. If the file size is > ~60meg it will not play with recent changes to Audio library. Any thing less than 60meg and it plays. I have a 102meg wav file that plays with @FrankB's Teensy-WavePlayer I had originally modified it to play wav files with DiskIOMB. It worked with all wav file sizes. When I try to play the same files with the modified wav player files in the Audio library they will not play. I remember back when I first had it playing with MSC I had to increase the buffer size from 512 to 8192 to get it to play. Tried that and it still failed.

It's getting late and I I'm kinda burnt out. Been messing with this all day. I also saw similar issues on the other thread. More tommorow...

Wonder if related to issue trying to figure out why MicroMod is faulting.

So far looking like a read failing and returning that it read 65535 bytes on a read of buffer of 512 bytes... And then the code passed that off and walked off to never never land.

Should probably at minimum update the wav player code to check for read size > buffer size.
More on other thread
 
Back
Top