[eckythump]

I can see a few possibilities here. One is that FreeSound does not free the sound right away but somehow flags it for delete or something. I have no idea what FreeSound actually does so this is just guessing. If this is the case, then the memory may become available later.
Another possibility is that when useCached=False, the wav is read each time. Perhaps this filling the disk cache. Does the memory usage you mention include the disk cache? If so, then this would be fine because it is still available for use. My understanding of Linux disk caching and memory usage reporting is not great, so I may have something wrong here, so let me know if I've said something stupid
I'm also not sure how writing or overwriting files to a tmpfs affect memory usage.

In any case, I still am going to try to duplicate the issue when I get a chance and see if I can figure anything out.
Please feel free to shoot down my assumptions and fill in the gaping holes in my Linux knowledge

My knowledge of linuxes memory systems is also patchy at best, but as far as I understand any kind of system-wide cache, such as filesystem level caches will chew RAM in other processes, not the xbmc process. Same with tmpfs.

I have had a look just now after leaving my pi idle overnight and the memory usage for the xbmc.bin process is still at what it was at when I stopped fiddling last night.

After a bit more usage, it'll start to get sluggish and unresponsive until it's practically unusable and a reboot is necessary.

Look forward to hearing back what you discover when you test. I'd also be curious to hear back if you get the same behaviour on non-pi/non-openelec installs, too. I currently only have the pi to test on, so am never sure if an issue I spot is universal, open elec specific, or pi specific.

Thanks for the perl/python server interoperability fixes. Appreciated. All your time and effort on this is very appreciated.