The two profiles for which the io response from idle is fairly rapid do NOT
actually work with my audio application - it still fails in the same manner.

With the app loaded, I decided to run the IOMeter test again. As I
suspected, the response time was slow again. For whatever reason, having the
app actually running has effected the io response time.

I think the main issue here is power saving states of the disk drive. I
have learnt that some drives do have multiple power savings states, such as
turning off the heads, or even parking the heads. Being a laptop drive, it's
hardly surprising that it's doing this.

Generating the background activity is an easy workaround for me for the time
being. I've just been using the app with a background random read of 512
bytes every four seconds (i.e a tad under the idle timeout), and it works
fine.

I think the subtle changes in behaviour with the various power savings
profiles are going to be very difficult to diagnose/explain.

Greg.