Wave files loader crashes when there is no grnltr.cfg

[KnightHill]

Wave file loader crashes when there is no grnltr.cfg. The same wave files load fine when there is a config file.

I did some debugging and it looks the following loop never ends (most likely the while condition).

do { f_read(&SDFile, (void *)buf, CP_BUF_SIZE, &bytesread); memcpy((void *)&sm[this_wav_start_pos], buf, bytesread); cur_sm_bytes += bytesread; this_wav_start_pos = (cur_sm_bytes / sizeof(int16_t)); } while(bytesread == CP_BUF_SIZE);

[KnightHill]

I also checked how wave files are loaded in libdaisy/wavplayer.cpp. It looks the end condition also checks for EOF:

if(bytesread < rxsize || f_eof(&fil_))

[jazamatronic]

Ok - let me take a look at the code and see if I can spot anything. Otherwise it will have to wait until the weekend when I can recreate it on hardware and get the debugger hooked up if needed.

Cheers

[jazamatronic]

A couple of questions - which platform are you using, bluemchen or pod? If it's the pod, what colour are the leds when it hangs? If it's bluemchen, what does it say on the screen?

Cheers

[jazamatronic]

I had some time to try this - I have a few folders under my grnltr folder on the SDCARD that don't contain any grnltr.cfg files - they all load just fine.
Can you double check the format and size of all the WAV files you're trying to load? If you have a folder that loads with the grnltr.cfg can you remove the grnltr.cfg from that folder and see if they load just fine? I pushed a new release with your suggested fix - i.e. checking for EOF in the WAV reading loop - maybe give that a try?

https://github.com/jazamatronic/grnltr/releases/tag/v0.99d

Cheers

[KnightHill]

I am running the code on a pod. The error code (LED color) is White.

[KnightHill]

I had some time to try this - I have a few folders under my grnltr folder on the SDCARD that don't contain any grnltr.cfg files - they all load just fine. Can you double check the format and size of all the WAV files you're trying to load? If you have a folder that loads with the grnltr.cfg can you remove the grnltr.cfg from that folder and see if they load just fine? I pushed a new release with your suggested fix - i.e. checking for EOF in the WAV reading loop - maybe give that a try?

https://github.com/jazamatronic/grnltr/releases/tag/v0.99d

Cheers

I use sox to convert the wave files, but will double check the format tonight.

sox 01o.wav -r 48000 -c 1 -b 16 -e s 01.wav

[jazamatronic]

So a white led means it had a problem opening a subdirectory under /grnltr. Are there any funky characters or spaces in your directory name?

[KnightHill]

Thanks for the quick response.

I will double-check, but I don't believe there are any subfolders under /grnltr or any unicode characters that are part of the folder/file names. The wave file names are very short (01.wav, 02.wav, etc).

I will try your new build tomorrow.

Also, I was wondering if there are any limitations as of how long the wave files could be?

Thanks

[jazamatronic]

I've been able to reproduce the situation here and I think I have a fix that will work for you, please try the following release:

https://github.com/jazamatronic/grnltr/releases/tag/v0.99e

Root cause is the code expecting to find subdirectories full of wave files under the /grnltr directory. It works when there is a grnltr.cfg, because it can find /grnltr/grnltr.cfg, but if there's no grnltr.cfg it tries to open something that doesn't exist and fails. I've updated the code to deal with this situation - please try it and let me know if it resolves this issue.

Having just 16 wave files under /grnltr/ was not my expected use case, I envisaged people having banks of 16 wave files, each under a separate subdir. If the above fix doesn't work, you could also try creating a subdir under /grnltr and moving your waves into that instead.

Cheers

p.s - total sample size is limitted to a little under 64MB - the size of daisy's SDRAM minus a small buffer reserved for live granulation.

[KnightHill]

Please keep in mind I usually use ST-LINK to program. The dfu-util command is giving me the following error:

dfu-util: No DFU capable USB device available

My df-util version is 0.11. make program-dfu used to work, but something happened during one of the last updates and that's no longer the case.

Thanks

[KnightHill]

I checked the "make program" command used to program with the ST-LINK. It uses openocd and the actual format is

openocd -s /usr/local/share/openocd/scripts -f interface/stlink.cfg -f target/stm32h7x.cfg \
    -c "program ./build/filename.elf verify reset exit"

I was wondering if you can provide an elf file along with the bin file so I try flashing w/o using the DFU. Hopefully that would not interfere with your automated build process.

[jazamatronic]

I've added the elf files to the latest release - please give it a try and let me know how you get on.

Cheers

[KnightHill]

Everything is as expected with the latest paths.

Thanks

[KnightHill]

closing the issue

[jazamatronic]

Great! Thanks for reporting and then testing the fix.