Thanks for your reply.
I'm using a sample rate of 44.1khz (required for C2 audio, I believe) with a bit depth of 16 bits. I've also reduced the size by setting the tracks to mono, rather than stereo. So I think they're as optimized as they can be, but it's still a lot of audio data.
Each track is linked to a separate page, and each page discusses a particular health issue. So I can tell when each track will be required.
I have tried loading each track a few pages before it was required. But with audio lag ranging anywhere from 6-12 seconds, this approach seemed to cause a few problems. Firstly, this approach still can't load the first track we require fast enough (so it's not ready when the first page loads). However, I had considered adding a controlled loader layout to overcome this problem.
Secondly I've tested on several mobile devices and each one handles the lag slightly differently (e.g. some devices play a track after 6-7 seconds and others take 10-12 seconds before the track is ready). This makes guessing when we should begin to load a track, quite difficult.
Thirdly, with so many tracks being loaded simultaneously (e.g. track 1 still buffering when I start to load track 2 for the next page etc.) some lower end devices just seem to give up all together, and crash the app.
It wouldn't be a problem if the C2 audio plugin could stream audio immediately (on mobile). But this lag issue is really throwing a spanner into the works.
Thanks again for the reply, if you have any useful ideas, I'm all ears