For responsible use of diskspace for the temporary files, I normally create a directory in the temp-dir, in which I store all my transient data, like /tmp/the-derp-game/*.wav. Upon launching the process (not upon exit), I cleanup old/big files in this directory, which I know only contains my files.

Having said that, TinySound really needs to stream audio right from compressed audio files, instead of unpacking it fully to disk and using that as a source for streaming. It causes extreme RAM usage and extreme disk usage. There is no reason for this (except limited dev-time), for an API that is meant to be used by other developers.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

For responsible use of diskspace for the temporary files, I normally create a directory in the temp-dir, in which I store all my transient data, like /tmp/the-derp-game/*.wav. Upon launching the process (not upon exit), I cleanup old/big files in this directory, which I know only contains my files.

+1 to that approach, probably combined with the not-exactly-foolproof deleteOnExit().

Having said that, TinySound really needs to stream audio right from compressed audio files, instead of unpacking it fully to disk and using that as a source for streaming. It causes extreme RAM usage and extreme disk usage. There is no reason for this (except limited dev-time), for an API that is meant to be used by other developers.

There are lots of benefits to working with uncompressed audio data too though - single CPU hit for decoding, better seeking, etc. Depends a lot on how the audio is being used. Problem in TinySound is the RAM hit from reading the sound file in one go before writing it to disk. Could do that better by chaining the input and output streams with a much smaller working buffer. It's hardly extreme disk usage!

I wasn't talking about the 1.82GB! That's caused by the bug with deleteOnExit() and not doing the cleanup you suggested. That's not in itself a reason for switching to streaming directly from the compressed file, as per your original argument. It's a good argument for fixing / working around the issue of temp files not being deleted. There's no way that you'd get anywhere near that level of disk usage if that was fixed, unless you're really using over 3hrs of audio data at the same time.

Not to mention that this is in a temp folder, and any decent OS should manage that for you!

So, does anyone know a simple sound library that doesn't use a ton of RAM and can play midi files?

Yes, the JRE. Since Oracle Java 7 or OpenJDK anyway. These have Gervill built in (though you can ship it separately), which is an excellent MIDI / live DSP system. Just make sure you give it a decent soundbank to work with (which you may need to customize if you want to keep RAM usage down).

The bigger question is, why you want to do this? Note this message and Cas' opinion (which I agree with). MIDI makes sense as a dynamic system, but not for playing static files.

Incidentally, if you go with Gervill, you'll also be in a position where you'll need to play your sound effects through it too - there was a discussion about this recently.

In general, I'd suggest that unless you have very particular needs outlined in those links, stick with TinySound.

Does any OS actually manage the temp-dir in more more sophisticated ways than "shall I wipe it now, or shall I wipe it later" ?

Well, just clearing it on reboot is a good start on a desktop system (general Linux desktop with TMPFS or otherwise), then some do clearing up of files that haven't been accessed in a set amount of time.

haven't done much in ligbgdx yet but pauls 3d sound one (if that is the name) crashed on just about every single file I opened. It was fast and much leaner but hard crashed all the time. So I stayed the hell away from it.

I dont wanna be a party pooper... but guysTinySound only wraps JavaSoundJavaSound is really really bad... There are SO many nice alternatives

Don't want to be a party pooper, but you don't know what you're talking about!

There are bits of JavaSound that are really bad, but the direct audio mixers are OK, and about the most low-level way you can interact with the soundcard. Open device, stream bytes - that's it! To say that TinySound just wraps JavaSound is rubbish - it provides a range of higher-level functionality on top of the usable low-level bits of JavaSound.

If you're going to suggest OpenAL as a "nice alternative", then to TinySound maybe, but not the JavaSound direct mixers - OpenAL is a higher level API - you could write a pure-Java equivalent outputting via the JavaSound direct mixers!

it provides a range of higher-level functionality on top of the usable low-level bits of JavaSound.

Isn't this what wrapping means..?

Not sure why you felt the need to reopen that discussion?! Wrapper isn't that well defined, but it's normally understood as a means of providing an alternative API, wrapping a native library or (possibly) some minimal additional functionality. Taking your argument to its illogical conclusion would suggest that games are just wrappers for the JRE!

I thought by saying "only wraps Javasound" @Cero was belittling what @kuusisto has actually provided in this library, and also showed a lack of understanding of what is and isn't useful / usable in JavaSound - the low-level Mixers, which are wrappers to the soundcard driver, are not too bad (though aren't necessarily mixers in the normal audio sense of the word).

but if I play them one after another so that they overlap digital clipping can be heard. What can I do to get rid of that awful clipping when files are overlapping? Also, is there a way to change volume for individual file?Thank you!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org