the situation with file loading times, MP3, and web streaming

[Austin Hicks]

people keep asking the same questions, so I figured I'd just answer
them really quickly, then link this mailing list thread every time
someone asks them. Everything here is related by the solution: rewrite
parts or all of Libsndfile. Libsndfile currently rates as my least
favorite mandatory library. There is sadly no alternative to it with a
compatible license: he did just good enough to become the standard.


Firstly, it was recently brought to my attention that loading large
oggs in Libaudioverse introduces a noticeable pause. If you are
experiencing this, be assured that a future version of Libaudioverse
will remove it. Wave files load suitably quickly, so if it becomes a
real problem then you can use them as a temporary workaround. You can
also consider loading sounds lazily or using multiple threads. It
should be faster than it is, but it's fast enough to be usable. The
issue isn't a bug on Libaudioverse's side. It isn't specifically
libsndfile's fault, but there is no quick fix I can just apply.


I've also been asked about web streaming. The answer is that we do
not currently support this unless you write it yourself with a push
node. You can download the file and use Lav_bufferDecodeFromArray on
it, but actually streaming is impossible via Libsndfile. I can't hack
it in, and I can't support just the formats Libsndfile supports. In my
investigations of the file loading performance, I found out that
Libsndfile unconditionally calculates lengths of some formats by reading
the entire file as an unconditional part of the open call, then resets
the position to the beginning. In case it isn't immediately evident,
this means that streaming will require downloading the whole thing first
at best or infinite loop at worst.


Finally is MP3 support. Due to legal issues, Libsndfile won't
touch this with a ten foot pole. I don't blame them. But there is a
way. The 5 major platforms all provide APIs for decoding MP3 and
license the technology on your behalf. Lack of MP3 will also cripple
web streaming.


I can't provide a time frame for this work, but it is higher
priority than it used to be due to the performance problem. This is
probably an additional 3000 or 4000 lines of code in the best case. And
of course the three above issues can't be improved individually, as they
require the same rather large and intimidating solution. All I can say
is that I consider everything here to be an essential feature of a
modern audio library, and you will have it before 1.0. But the initial
launch is going to have to be without it.


Looking down the path of development, I see a future in which the
only mandatory dependency that I cannot vendor is boost. This isn't
because I want it to be. It's because everything you might use for this
stuff either has an incompatible/difficult license or is crap in terms
of performance or code quality. But usually it's got an
incompatible/difficult license and is crap in terms of performance and
code quality.


While disappointing, I hope this at least clears up why we don't
have nice things.