When playing an mp3 from an smb server, the source gets 64k read requests that have over 60k of overlap. giosrc caches the last buffer it read, but only uses it if it can completely satisfy the next read request. The end result of this is that giosrc issues each of those 64k read requests to the smb server as-is, which means a lot more network traffic than is required to play the file. Somewhere around 30Mbit/s to play a 320kbps mp3 file.

Users notice this sort of thing when trying to play files from a network share in rhythmbox, and they see strange results like being able to play files when using a wired connection, but not over wifi.

It seems particularly bad with mp3s, probably because whatever's deciding it wants 64k buffers is mp3-specific. I think I saw it in mpegaudioparse, but I may be misremembering.

I'm attaching a patch that makes giosrc partially satisfy the read from the cached buffer and only read the rest, which makes everything look much more sensible. The read requests sent to the server are much smaller, which may not be a great thing overall.