Okay, ReserveCache fixes all but the very first glitch for me, even if I completely comment-out the Hijack CPU-yielding hack.

Based on various observations (a bit too complex to explain here), what is happening on my player is a very obvious "low memory" condition, which is causing various threads to block on memory allocation when they normally would never have to block.

This seems to only happen when the disk read-ahead in the player is busy, which makes sense since that activity will tie up a lot of pages in the kernel for holding the disk reads before they get copied to userspace, making even the most trivial of memory allocations result in a process blocking.

For example, opening an FTP connection to my in-kernel kftpd was NOT POSSIBLE during the disk I/O, due to lack of memory for the new thread's stack allocation (it needs 12kB total: 8 for stack, plus 4 for a parameter/buffer block). I saw other indicators of extreme low memory as well.

Pity we don't have O_DIRECT in this kernel version --> O_DIRECT forces disk reads directly into the userspace buffers, bypassing the page cache completely for apps which roll their own, like the player.

As a sidebar, I recently added the "--direct" flag to my hdparm utility, to permit benchmarking with/without direct userspace I/O, and it the difference with the RAID controller I'm working on is most impressive: a 4-drive RAID10 jumps from 70MB/sec to 130MB/sec, and a 4-drive RAID0 whooshes along at 206MB/sec. On a slow CPU using 64-bit/66-Mhz PCI, that is.

Now, for the first glitch, which still can happen. I don't hear it, but I see the W icon flash, which means the software knows it had a glitch. The Hijack CPU-yield on disk I/O is imperfect --> it misses the first FID that is read, so it is possible for a large initial track that the readahead of that same track may still glitch, on both v2.03 and v3alpha. I'm unlikely to fix that one.

Cheers