[gst-devel] libsndfile and files in memory

[Steve Baker]

Hi Erik

At linuxconf I promised that I would describe to you changes to libsndfile
that would allow us to do cool things with it in GStreamer.

Currently in GStreamer we can create pipelines like this:

sndfilesrc location=foo.wav ! volume ! alsasink

What we'd like to do is pipelines like this:
filesrc location=foo.wav ! sndfiledecode ! volume ! alsasink
httpsrc location=http://gstreamer.net/media/foo.wav ! sndfiledecode !
volume ! alsasink

and now sndfiledecode can be used for autoplugging, so we can use a
completely generic pipeline:
filesrc location=foo.wav ! autoplugger ! volume ! alsasink

To make this possible, IO in libsndfile will need to be virtualised so that
it doesn't have to directly access the filesystem.

Looking at the libsndfile source this job seems to be half done already so
hopefully it won't be too much work.

One common approach is to just have callbacks for the io operations. A new
sf_open_something() function could be used to pass in the callbacks.

An example of this approach is the vorbisfile api:
http://www.xiph.org/ogg/vorbis/doc/vorbisfile/overview.html
http://www.xiph.org/ogg/vorbis/doc/vorbisfile/ov_callbacks.html

and the vorbisfile GStreamer plugin implements the callbacks as
gst_vorbisfile_{read|seek|close|tell}
http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/gst-plugins/ext/vorbis/vorbisfile.c?rev=1.51&content-type=text/vnd.viewcvs-markup

The way the read callback is specified means that we have to memcpy the
data into it. It would be a nice optimisation if we could just pass in a
pointer to the raw data. However the data might be read-only, so if you
need to write to that memory area then the optimisation probably isn't
worth it.

I understand that some audio formats would require a lot of seeking to
detect/decode. This won't be a problem for GStreamer as long as the source
element can seek (or an element between the source and libsndfile can fake
seeking).

I guess its would also be nice to virtualise the file writing as well, so
we could have pipelines like:
alsasrc ! volume ! libsndfileencode format=aiff ! filesink
location=foo.aiff
so there would also be a need for a write callback (which would be null in
the read-only case).

Internally in libsndfile you could have your own file IO based callbacks
which get hooked up when you call sf_open and sf_open_fd. This would allow
you to play around with your memory-mapped file IO callbacks without
ripping the guts out of your existing working standard file IO ;)

Anyway, let me know what you think.

cheers

-- 
Steve Baker <steve at stevebaker.org>