Hi All,
I seem to have found a minor bug in aplay, within alsa-utils 1.1.4. It's possible that I'm the first person who's ever hit it. This appears to be the correct place to report it; if not, I humbly apologize, and ask for direction on where to submit this.
In aplay.c, around line 3030, we do this calculation:
max_file_size = max_file_time * snd_pcm_format_size(hwparams.format, hwparams.rate * hwparams.channels);
We do this to convert max_file_time from the '--max-file-time' parameter (an int) into max_file_size, a file length in bytes (a long long). Since snd_pcm_format_size() may return something 32-bit, this might overflow 32-bits when we do the multiplication, wasting the extra bytes of max_file_size.
On my test case on an armv7l system, a 1800-second file at 192 KHz recorded in S24_3LE doesn't overflow, but recording in S32_LE does. I accidentally found an edge case. In case anyone wants to know, the failure mode is that arecord will repeatedly create 44 byte .wav files very quickly, since these are larger than the negative max file size. This continues until you have a directory full of thousands of 44-byte files. Hilarious.
A simple change to cast max_file_time to a long long fixes this in my test case. There might be some cleaner solution, but this at least worked for me.
max_file_size = (long long) max_file_time * snd_pcm_format_size(hwparams.format, hwparams.rate * hwparams.channels);
Hopefully someone can vet this and carry it over to git. I've attached a patch file as well.
--
Additionally, while working to report this, I noticed that the bug tracker link on the sidebar of https://www.alsa-project.org/main/index.php/Main_Page is a dead link.
-Scott