Hi all, While reading through various bits of libvorbis and vorbisfile, and then thinking about how to implement other features in the xmms and winamp plugins, I had some thoughts... Vorbisfile is very useful, and very easy to use. It is, however, tied to stdio - which means you can't use it for lots of other stuff where it'd be useful - like streaming, or (under win32) avoiding stdio and using the win32 file functions (which might have some advantages). Reimplementing much of vorbisfile, or copy/pasting it into another program, seems to rather wasteful, and vorbisfile does everything that a decoder needs. More than 95% of the vorbisfile code doesn't actually care about the underlying data source, however. Looking through it, we see a total of 4 functions called: fread() fseek() ftell() fclose() It would seem useful to modify vorbisfile to abstract the functions used for reading, seeking, and closing a file. A seperate version of ov_open() could be available, which would take 3 extra arguments - to function pointers for these functions. We don't really need ftell() - it is solely used to get the file length, and there are a couple of ways we could do this - either an extra argument to ov_open(), or make the seek function return the current file position (these functions need not map precisely to the stdio equivalents, though they'll be close). I've played around with this a bit, and have a compiling (but untested) version that does this - it needs cleaning up a bit first, but I think it's basically a good idea. So - what do people think of doing this? It would make vorbisfile much more useful, at the expense of very little added complexity (and if we retain the current ov_open() call, none except when the extra functionality is needed). If it is agreed that this is worthwhile, I'll clean up what I have, and send it in for criticism. Michael --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/
> So - what do people think of doing this? It would make vorbisfile much more > useful, at the expense of very little added complexity (and if we retain > the current ov_open() call, none except when the extra functionality is > needed).I agree that it's a good idea. For e.g. the game I am working on, I'm going to want to stream long audio tracks in a fully asynchronous way (you can't stop to read from disk, as you'll drop frames). Being able to abstract reads is just the right thing; if it's restricted to using stdio, I cannot use vorbisfile at all unless I do funky thread things that I am unwilling to do. I have not looked at vorbisfile enough yet, but it's not yet clear to me how randomly it's going to try to seek around the file... I assume that since everybody thinks streaming is good, the answer is not too much... -Jonathan. --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/
> Vorbisfile is very useful, and very easy to use. It is, however, tied to > stdio - which means you can't use it for lots of other stuff where it'd be > useful - like streaming, or (under win32) avoiding stdio and using the > win32 file functions (which might have some advantages). Reimplementing > much of vorbisfile, or copy/pasting it into another program, seems to > rather wasteful, and vorbisfile does everything that a decoder needs.Martin Vogt has already written the patch you suggest. I have a minor tweak I want to make to it before committing it to mainline. It's all bottlenecked on me again :-(> A seperate version of ov_open() could be available, which would take 3 > extra arguments - to function pointers for these functions.Actually, a structure of functions, because there's more callbacks that I want to add than just three stdio functions. Monty --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/
> So - what do people think of doing this? It would make vorbisfile muchmore> useful, at the expense of very little added complexity (and if we retain > the current ov_open() call, none except when the extra functionality is > needed).I like this a lot -- the main reason why I never looked at vorbisfile seriously is streaming -- when the data doesn't come from a file. If this shows up in cvs then I will just use that interface and not bother to deal more with the pcm integer patch... --ruaok Freezerburn! All else is only icing. -- Soul Coughing Robert Kaye -- robert@moon.eorbit.net http://moon.eorbit.net/~robert --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/