[Bug 705415] New: [gio] incredibly inefficient when playing mp3s from smb servers

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=705415
  GStreamer | gst-plugins-base | git

           Summary: [gio] incredibly inefficient when playing mp3s from
                    smb servers
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: notverysmart at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.