Forum Rule: Always post complete source code & details to reproduce any issue!
Page 4 of 5 FirstFirst ... 2 3 4 5 LastLast
Results 76 to 100 of 114

Thread: Now for MP3 with FS...

  1. #76
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,613
    Quote Originally Posted by KurtE View Post
    Try syncing up to my USBHost_t36 FS_Integration_MSC branch... I believe the AAC and MP3s are now working without changes to core.
    Click image for larger version. 

Name:	2021-12-04 11_12_29-Window.png 
Views:	19 
Size:	5.8 KB 
ID:	26784

    Is there a case where it is not on the heap?

  2. #77
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,613
    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 by Frank B; 12-04-2021 at 11:05 AM.

  3. #78
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,613
    Is it needed to flush it? If it gets overwritten anyway (by the read), an arm_dcache_delete() would be faster.

  4. #79
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,613
    Quote Originally Posted by Frank B View Post
    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?

  5. #80
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,867
    Quote Originally Posted by KurtE
    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

    Quote Originally Posted by Frank B View Post
    I've fixed FLAC (Tested with 3.6 only - T4 seems to be not reliable at the moment?)

    https://github.com/FrankBoesing/Ardu...332bfae175ccf8
    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.

  6. #81
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,867
    Ok just issued 2 PRs

    1. Request to update the Audio library with changes to play_sd_wav and play_sd_raw: https://github.com/PaulStoffregen/Audio/pull/419
    and
    2. Request to @wwatson to update his fork of Franks lib with all the changes for FS: https://github.com/wwatson4506/Ardui...dec-lib/pull/1

  7. #82
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,492
    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.

  8. #83
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    10,007
    Quote Originally Posted by Frank B View Post
    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...

  9. #84
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    10,007
    Quote Originally Posted by PaulStoffregen View Post
    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.

  10. #85
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,613
    @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..

  11. #86
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,613
    Quote Originally Posted by mjs513 View Post

    2. Request to @wwatson to update his fork of Franks lib with all the changes for FS: https://github.com/wwatson4506/Ardui...dec-lib/pull/1
    If you (@wwatson) do a PR, I'll merge it.

  12. #87
    Senior Member wwatson's Avatar
    Join Date
    Aug 2017
    Posts
    619
    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...

  13. #88
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    10,007
    @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

  14. #89
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    10,007
    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**********
    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...

  15. #90
    Senior Member wwatson's Avatar
    Join Date
    Aug 2017
    Posts
    619
    @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((void *)sectorBuffer, (uint32_t)(Blocks * BlockSize));
    In the "msReadBlocks()" and "msWriteBlocks()" functions. Hopefully that is correct

    @all - Thanks for all the help with this

  16. #91
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    10,007
    Yes I thought I pushed up change for the cast

  17. #92
    Senior Member wwatson's Avatar
    Join Date
    Aug 2017
    Posts
    619
    Quote Originally Posted by KurtE View Post
    Yes I thought I pushed up change for the cast
    Awesome. Got one right

    Hopefully will get a chance to play with MTP with all of the recent changes...

  18. #93
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,613
    @wwatson,

    Thank you for the PR

  19. #94
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    10,007
    Note: I am going to take the MicroMod issue over to the integration thread as it is not really related...

  20. #95
    Senior Member wwatson's Avatar
    Join Date
    Aug 2017
    Posts
    619
    Quote Originally Posted by Frank B View Post
    @wwatson,

    Thank you for the PR
    Thanks for a great AudioCodec library

  21. #96
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,867
    @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

  22. #97
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,613
    Thanks

    and..it worked all the time (ok, till last month when encryption was added... :-)

  23. #98
    Senior Member wwatson's Avatar
    Join Date
    Aug 2017
    Posts
    619
    @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...

  24. #99
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,613
    What is "DiskIOMB"?

  25. #100
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    10,007
    Quote Originally Posted by wwatson View Post
    @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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •