Yeah you're evenly creating the buffers over time, but you're not reusing them but rather always creating new ones as you go. I don't know the API well enough but is there some way you can recycle AVAudioPCMBuffer objects once they're done playing?
That's probably a good idea. There doesn't seem to be any reason you can't, as long as you wait for the buffer to become unscheduled before refilling it. You could even use that to drive the buffering logic: allocate all the buffers you want at once (hopefully keeps the allocations near each other), and store them in a collection if they are ready to be filled.
1 - Thanks for the suggestion. Other than reducing the garbage collection (or Swift's equivalent) overhead and the one additional thing temporarily in memory (i.e. the buffer that just finished playing and is now waiting to be collected), is there another benefit to reusing buffers ?
Keeping the added complexity of your solution in mind (i.e the risk of re-playing old data which is still sitting in the same buffer), is the benefit worth it ?
Again, this is a balancing act. I don't doubt that your suggestion has benefits. I'm just wondering whether it is really worthwhile to reuse buffers, given the risk/complexity it comes with.
2 - A new question for both of you - I'm thinking of a way to potentially speed up playback start (i.e when a user clicks play or next/prev track) ... when the app loads up initially, I eagerly "prepare" the
first track for playback, and whenever a track starts playing, I eagerly prepare the
next track for playback, so that it is ready (to the extent possible) when the user clicks next or the previous one finishes playing. Of course, the prepping of the next track will be done asynchronously in a background thread, while the current track begins playing (or when the app initially loads up and nothing is playing yet). This "prepping" includes 1 - reading metadata like sampleRate and total frames, and 2 - possibly even reading that first small buffer of actual audio data ... to keep it ready for when the track is actually played. Of course, the assumption is that the user will not alter the playback sequence between the time the eager prepping is done and the prepped track actually starts playing. If he does, by double clicking a random track that hasn't been prepared yet, I'll just load it normally (just in time), but accounting for the most common case (where the app is just running in the background and the user is busy doing something else), it is fairly easy to figure out which track will play next and eagerly load some or all of the initial data required (1 - metadata, and 2 - the first small buffer of audio data), one track at a time. So, to summarize, I can always "look ahead" one track into the future, and keep it ready.
So, the question is - how would y'all do something like this ? Are there any potential downfalls to doing something like this ?
In pseudocode, I'm currently doing something like this:
Code:
func play(track) {
player.play(track)
dispatchAsyncToGlobalQueue {
// Figure out which track is next in the current playback sequence, depending on repeat/shuffle mode
let nextTrack = figureOutTheNextTrack()
// Eagerly prepare it for playback
prepare(nextTrack)
}
}
