Ian, I ended up switching back to NOBUFFER streams because the memory usage of BUFFER streams was not workable on an iOS device in my use case. I ended up implementing a ring buffer to buffer my NOBUFFER file streams so that the BASS output buffer can remain fairly small for seeking to be quick, but I can still have a large buffer to prevent underruns. It's working very well, no issues there, that just brings me to the issue I discovered today:
I noticed today that when playing FLAC files, the BASS_ChannelGetData function works differently than for all other types of files. For all other file types, if the read proc returns 0 bytes, then BASS_ChannelGetData simply returns 0 bytes. However, for FLAC files, BASS_ChannelGetData blocks until it can return the number of bytes requested.
The causes a problem because it immediately stops audio output even if my ring buffer is full, it breaks my code that pauses the playback temporarily when there are underruns and the ring buffer is empty to prevent choppy playback on poor connections, and it sits at 100% cpu utilization while waiting for data because it bounces back and forth between the file len proc and file read proc.
Also, if I don't pause and wait for more data to be downloaded, BASS_ChannelGetData will keep blocking for each read and produce stuttering and even worse, after the connection is fast again there is still massive stuttering until I seek. My pausing code eliminates that problem and works fine for all file types that allow 0 to be returned by BASS_ChannelGetData.
Is there some reason that the behavior of the user file stream procs is different for FLAC than all other formats? I understand it's a plugin, but so are the CoreAudio codecs (correct?) and they work fine.
Could you fix it so that when reading FLAC files, the read proc is not retried over and over until data is available and it simply returns 0 for BASS_ChannelGetData like other file types do? That would completely fix the last of the issues I'm experiencing.