You need to remember what buffer came from what file and share them between the sources.  If this doesn't cut it down enough, you need to unload buffers that currently aren't needed.  No algorithm for actually editing the data inside the buffer is going to make it smaller; all you can do is share the data between all the sources using it or knock stuff out of ram to make room.  Finally, if music isn't streaming, get one of your libraries doing that for you.  I'm certain FMod has support for streaming from disk.
But realistically, assuming you're targeting this community, you need to run comfortably in 2 GB of ram.  1 would be way better if you can get it, because who knows what's open on the box.  Very, very few people here are going to have more than 2 GB, let alone actually having 2 GB free for you to allocate.  Many here will only be running on 1 GB because they cannot afford a new box and are thus running on something from 2008 or 2009.  Most sighted people don't have that much free ram anyway.  If you were to do a game for the sighted with a 4 GB free ram requirement, most people would simply walk away.  This sounds like either lack of deduplication (you're loading every file over and over instead of keeping one buffer and reusing it) or a bug (could be anything that eats ram, anything at all. Do not limit yourself to sound.  Damningly, it may not be your fault or something you can even fix).  But you should be able to cut your requirement down to way under 4 GB if you fix it.
There's not really a novel algorithm that will make OpenAL buffers smaller, save resampling your audio at lower sampling rates.  This will be a huge drop in quality, if you do it.  If you need to squeeze a bit more, make sure that you don't have a lot of sounds ending in a few seconds of silence.

Then, assuming your sounds are big enough, you need to write your own streaming system.  It doesn't matter whether you mean 4 GB free or 4 GB total.  Most of the people here do not have 4 GB of ram.  If you want people to play your game, you need to aim for 2 at most, but really I'd aim for 1.
OpenAL buffers can be queued, and therefore you can do it.  I've done it in the past.  It's not even that difficult.  Your problem is that ruby is just about as far from gaming as you can possibly get, so yes, you will need to do a lot of this yourself.  If your OpenAL wrapper doesn't support separating sources and buffers, then you're screwed and there's almost nothing you can do for large sounds.  OpenAL itself separates the concepts, but some bindings make it "easier" by exposing them together.
You should also convert anything meant to be played through a positioned source to mono.  OpenAL will use half as much ram for mono sounds versus stereo ones.  For panned sources, OpenAL will usually just crush the stereo sound at runtime; since the buffers can't be shared, however, the buffer is still holding twice as much data.  If you're using stereo sounds with panned sources, you'll also sometimes hit other bugs.  I've seen some implementations of OpenAL only use the first channel of the buffer instead of squashing it for you.
Literally nothing else in this community comes close to using as much ram as you're using.  As I understand it, your game is commercial.  If your game requires this much ram, then I doubt many people are going to buy it from you.  If you are going to sell your game, then buy FMod and save yourself the trouble, because OpenAL isn't really going to give anyone HRTF anyway, not unless they're advanced enough users to edit an ini or you're using OpenALSoft explicitly and your wrapper supports forcing it to turn on.
Look at your map format.  If the problem occurs when you load maps, then maybe it's not even sounds at all.  You're saying that it's not a problem until you load a map, maybe your array is horribly inefficient.  Languages like Python and Ruby are bad at 2D arrays, so you can usually save a lot by wrapping it in a class that uses a list or the equivalent and does a few basic calculations to find the tile or whatever.  This can cut the overhead of map data in half: you are no longer storing the keys, and the keys can take as much ram as the values.  Assuming your tiles aren't integers, you can also deduplicate them: create each unique type of tile only once and then reuse the instance over and over.
I'm not sure why you're fixated on sound.  Create a test program. Load every single sound in the entire game.  See how much ram it's using.  Convert every sound in the entire game to .wav, see how much hard drive space it takes.  If these numbers are not close to each other or off by approximately a factor of two or four, then you get to blame your OpenAL bindings for introducing a ton of overhead.  If it's reasonable, then you need to look elsewhere for other problems.  But you should benchmark everything separately at this point and find out what bit of code is actually causing the problem.  I would have to try very hard to have enough sounds that they'd actually take up more than a GB of ram.  Swamp stops well short of this point and has more sounds than anything I've ever seen.  People have full-fledged, long RPGs working on the iPhone with huge 3D models and fully acted cutscenes and all that.  I wouldn't be surprised if all the work you want to do to optimize your sound system comes down to almost nothing in the grand scheme.   Better to find out for absolute certainty now instead of in 3 weeks, because this really sounds like it may not be the problem you think it is.

@Camlorn, there is a game that uses much, much more RAM than this game will ever use unless he loads every sound at 196 or 320 KHz and that is MK x. That game requires 8 GB of RAM, and many, many people play it; it's just not very many people in this particular community have 8 GB of RAM, although it is extremely highly recommended to have 8 GB or more. The only reason people can't afford one of those types of computers is because the computer companies sell them at ridiculously high prices. (Ahem: Apple: Apple Mac 2015 machine for $1,800.00 to $2,000.00). Of course, I've seen worse. There's a machine out there that's $13000.00 and is entirely meant for gaming.