pcm_file: retry write(2) on short writes in safe_write()

alsa-project/alsa-lib pull request #521 was opened from Krishnanand-G:

Fixes #63.

The file plugin drops audio when its output is a FIFO but not when it's a regular file. Looking through pcm_file.c, safe_write() only retries write(2) when it returns -1/EINTR. On a pipe, a blocking write that's interrupted by a signal after part of the buffer already went through returns the partial byte count instead, not -1. safe_write() passed that short count straight back, and snd_pcm_file_write_bytes() treats "wrote less than requested" as a reason to stop and return success, so the rest of that period's samples never made it out.

That also matches why regular files never showed the bug: a write to a file rarely blocks long enough for a signal to land mid-syscall, while a write to a FIFO sits blocked waiting on a reader constantly.

The fix is small: make safe_write() keep writing until the whole buffer is out or a real error comes back, instead of stopping on the first partial write.

I wrote a small standalone repro outside the tree (pipe with a small buffer + slow reader + SIGALRM firing during the write) to confirm the mechanism before touching pcm_file.c. With the old loop the writer reliably loses most of a 512KB buffer (~12KB gets through per run); with the retry loop all 512KB gets through every time despite the same interruptions. Also ran a full `./configure && make` of the library to confirm it still builds clean.

I didn't have a real FIFO consumer / hardware set up to exercise this through actual aplay/arecord, so if anyone hitting #63 wants to try this against their original setup, that would help confirm it end to end.

Request URL   : https://github.com/alsa-project/alsa-lib/pull/521
Patch URL     : https://github.com/alsa-project/alsa-lib/pull/521.patch
Repository URL: https://github.com/alsa-project/alsa-lib