questions on HRTF, estimating memory consumption and streaming from encrypted files
John
Hi
Creating a new thread to avoid being too off-topic.
1. How does 3d sound/HRTF compare with OpenAl-soft's? From my limited experimentation with OpenAl-soft, getting the sense of whether something is above/below you is the hardest part.
2. How do you estimate how much memory a .ogg would use if you create a buffer from it? My current simplistic approach is to preload all short sounds before the game starts.
3. How would you support streaming from some custom file format like an encrypted sound file? I see this being mentioned in the push/pull nodes, but am unsure how it works.
Austin Hicks
The memory usage of any audio file loaded into a buffer is
channels*sample_rate*length plus a small overhead, where
sample_rate is the server's sample rate (usually 44100) and length
is in seconds. If you are using large files, you can use a
FileStreamingNode. Allowing buffers to remain encoded is
difficult because decoding isn't exactly inexpensive or set up to
let you access arbitrary samples. For the most part, the rest of
Libaudioverse will fit well within 20MB of free Ram; without using
buffers, you will run out of CPU first.
I think my HRTF is more natural sounding. The OpenALSoft HRTF
uses an algorithm which allows it to be faster, but it has to
sacrifice a *lot* of quality, so you get something that sounds
hollow for lack of a better word. There's also a lot of ringing
and other filter artifacts. Admittedly, I think his is better at
vertical. But still not enough to aim vertically, as we
discovered when I did the 3D asteroids game with camlorn_audio
(never released. For good reason). In terms of implementation,
Libaudioverse's can be reliably enabled but OpenALSoft's can't.
In addition, OpenALSoft places arbitrary limits on your source and
buffer count by default. If I recall this is around 256 or so,
but it turns out this is actually problematic because of how it
uses buffers, needing you to jump through hoops for any sort of
streaming. Given that this latter thing is one of the reasons
camlorn_audio never worked well, it's worth mentioning.
The story surrounding encrypted files is lacking. It's very hard
to do it until Libaudioverse supports static linking, as you can
unencrypt it with some effort by just spying to see where the
callbacks are. I also can't put decryption in Libaudioverse
because it is open source, meaning that anyone can extract the key
from your executable and then run whatever encryption routine is
in there. If you have a good design for this generally, I am very
interested.
Specifically, the push node allows you to shove samples at it,
which it will resample and output. The pull node calls your
callback. With these, you can implement streamers yourself that
read from your encrypted format without ever having the whole file
decrypted at a time. Which you want to use depends greatly on
you. I know this is not easy.
If all you need is a somewhat reasonable level of protection, it
may suffice to put all your files in an encrypted sqlite database
or something along those lines, write them one at a time to a
temporary directory, load the buffers, and then delete them. This
can be broken in several ways, but is certainly harder than
copying files out. This discussion has drawn to my attention the
fact that there is currently no good way to just load a file from
an in-memory array. I'll look at this, as it shouldn't be an
incredibly hard thing to add.
In the long run, I may develop and license sound encryption
technology. This whole thing is made difficult because the source
being generally available is the worst nightmare of anyone who
needs to actually encrypt sounds. Here, sound encryption. Now
have my free decryption program, everyone. And there goes the
effectiveness of it, since the app does have to have the key in it
somewhere.
--
You received this message because you are subscribed to the Google Groups "libaudioverse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libaudiovers...@camlorn.net.
To post to this group, send email to libaud...@camlorn.net.
To view this discussion on the web visit https://groups.google.com/a/camlorn.net/d/msgid/libaudioverse/007001d1ea8c%240765fb20%241631f160%24%40gmail.com.
Austin Hicks
I realized a few minutes ago that I forgot a 4. Memory usage is 4*channels*sample_rate*length plus a small overhead. Sorry.
--
John
So this gives memory usage, in bytes?
How difficult would it be to support static linking? I know that at least libsndfile has to be linked dynamically due to LGPL. Am not sure how much of a security issue that would be.
There’re some demos out there on youtube of mainstream games having good vertical HRTF. How hard would it be to replicate that?
No design in mind for now about the encryption. I’m at the stage where I need to seriously start thinking about asset protection, but won’t have to implement that for a couple of months. I guess this is another thing that would benefit from more people using libaudioverse in 0.9.
To view this discussion on the web visit https://groups.google.com/a/camlorn.net/d/msgid/libaudioverse/ccc9cead-65b8-986d-9e4b-81a5ea01dd8e%40camlorn.net.
Austin Hicks
yeah, that's the memory usage in bytes per-buffer. It could
theoretically be cut down to 75% or even 50% of that, if it's a
problem; 16-bit samples are probably good enough, but 24-bit
samples are certainly good enough. It uses floats for efficiency
and the 24-bit case introduces some overhead because the samples
aren't aligned, so I haven't tried to reduce it yet. Also, I'm
not sure it's a problem as long as you stream music. Since I know
you know what this is, all of Swamp could be loaded into
Libaudioverse buffers and the game would still be under 2GB ram
usage.
I've seen a few demos from time to time with good vertical HRTF, and it is something I'm going to work to improve. What we have does already work, though. The issue is that I remain to be convinced that it can ever be good enough for vertical aiming.
OpenALSoft has a better vertical HRTF, if you don't mind the artifacty filters. Back in the days of camlorn_audio, I wrote a prototype 3D asteroids. You had a turret that could be rotated in all directions and enemies that came in straight at you. Me and a few friends all tried it. No one could hit them until I added in the special radar that queued you into how much up or down you needed.
Before I get into possible future improvements, the sounds you're using also make a big difference. Most of the demos I've seen go out of their way to show off the kinds of sounds that work. A pure sine wave with HRTF applied will not sound like you did anything but (maybe) changed the volume. A drum track, explosion, or good-quality electrical noises with HRTF applied will sound really good. A piano track sounds kind of average, because pianos aren't very rich in terms of frequency content. The closer you are to the pure sine wave, the worse it works. Sharp, quick sounds that repeat also work better than very continuous sounds.
What Libaudioverse needs is to replace the FIR filters with linear-phase IIR filters and then to model the delay that is introduced from your head. At the moment, we just use some preprocessed numbers from MIT from around 1995. I'm going to do this at some point, but it's the kind of thing that we can safely call a mathematical adventure. I think it would improve the quality of it and it would certainly improve the performance. The downside is that it locks the HRTF data to one sample rate. We theoretically have the ability to resample them at runtime now, but in practice that is a bit off currently.
Beyond that, I need better data than what is publicly available. Someone could get me access to an anechoic chamber for about a week (because I don't know what kind of data I need till I try to use it), buy me a model head and various high-quality microphones, pay for my plane tickets and hotels, and provide a sighted assistant who is capable of doing science to take some precise measurements and manipulate the setup. Otherwise, it won't be happening anytime soon. Fortunately, other improvements may be enough.
To view this discussion on the web visit https://groups.google.com/a/camlorn.net/d/msgid/libaudioverse/002c01d1ec7b%24f4e4c160%24deae4420%24%40gmail.com.