I was assuming that memory for buffer was trivial (well .. there is still the "its all in use" limit of course) and that was unlikely to be a barrier
...
...
...
Does this have to be buffered on-chip? I assumed there was some any-old-RAM lying around (might not be the case, I have no idea what the layout is).
The most obvious point to make is: No-one who hasn't signed an NDA knows how it's arranged/setup/what's permitted so it's all speculation (AFAIK).
But since speculation is fun....
I think the reality is that "Caching" - a la phone Spotify download-this-playlist - is off the cards. Introduces too many variables, too many new config options and too many risks-of-breakage to be worth it for the limited market (bearing in mind the US cars still have Slacker). This might change if/when the US switches to Spotify, as the rewards for developing start to outweigh the risks & costs. The amount of available "Cache space" is also doubtful - the 4GB MMC is right out, that's reserved for OS/logging, and the amount available on SD cards is probably not reliably reservable (I understand especially on older cars with presumably smaller SD cards they're pretty full with map data anyway). And then you'd have to manage it, aging out by least-used or some other metric. Adds quite a lot of complexity to what we already know is a fairly basic client.
"Buffering" - by which I think we mean "download the whole song in one go and play it from local memory" - is entirely dependent on the onboard memory. Which, remember, has to hold the screen buffer, the display assets for the screen (Hmm. Does turning the vector maps into a displayable screen image take more or less memory than the Google Earth Satellite tiles? Dunno... either way, at that resolution it's a non-trivial amount), and all the other high-priority stuff (I imagine the audio bing-bongs, in particular, are kept in memory. Last thing you want when Autopilot dies is for the notification alarm to be swapped-out to disk when it's needed....). Bearing in mind the recent issues with screen display assets being corrupted and requiring a re-boot (...thus re-load from MMC) to clear, there's obviously a fair amount of memory in-use for data. ANYWAY, the point is, bear in mind MCU-1 is a 2010-2012 hardware design, so I'd be amazed if there's more than 1GB memory involved (my 2012 Google Nexus 7 tablet used the same chipset as MCU-1, Tegra3, and had 1GB memory). That won't leave much space for buffering but then even 5MB of MP3 at 128KBit is enough for a 5 minute tune and there's plainly not even that much being buffered by Spotify....
....Against which, when loading a Podcast in Tunein one can easily observe from the skip-to bar's colour how much of it is downloaded and I've been able to (once loaded) skip ahead 30 or more minutes.... Lower bandwidth but still 20-30MB's worth if one loads the same podcast onto one's computer or phone.....
SO: It's clearly a design-choice (or more accurately a lack-of-choice) to have a small onboard buffer for Spotify, that was probably justifiable at the time it was done but hasn't been looked at since. But then, it's fairly clear that the Spotify Client hasn't actually been very high up the list of priorities for attention for quite some time so who knows what the scope is let alone what's likely?
So, as with all speculative posts: Lots of words ending in a big "Dunno".