Need a really simple library for playing sounds and music? Try TinySound.

[nsigma]

I have 1.82 GB of undeleted TinySound garbage.  I feel like maybe deleting the files wasn't originally accounted for in the source?

I was about to suggest deleteOnExit(), but it appears the code already use this.  However, it looks like there may be bugs with this, particularly on Windows, if the file is still open on exit.

Not saying this is the cause, but from a quick look at the code in the mixer - https://github.com/finnkuusisto/TinySound/blob/master/src/kuusisto/tinysound/internal/Mixer.java - it seems that MusicReferences (unlike SoundReferences) are not disposed when removed?

[Riven]

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.

[nsigma]

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!   

Games published by our own members! Check 'em out!

[Riven]

You can decode mp3/ogg on a separate thread, so it won't affect your main loop. Very few games (here) use all cores of a CPU.

Regarding diskspace: on a HDD I'd agree with your that 1.82GB is barely significant, but on an SSD... it's a different matter, IMHO. Suddenly, diskspace is limited and/or expensive again.

[nsigma]

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! 

[Riven]

So much for me jumping in a thread, clueless about its context



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

?

[tyeeeee1]

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

[nsigma]

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.

[Cero]

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

come on now :/

[StumpyStrust]

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.

Games published by our own members! Check 'em out!

[nsigma]

I dont wanna be a party pooper... but guys
TinySound only wraps JavaSound
JavaSound 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!

[Quarry]

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

Isn't this what wrapping means..?

[nsigma]

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).

[lithos]

<3 I got it working in 20 mins, from not knowing anything about sound.

[Terraviper-5]

Nice library, but I have a little problem. I am writing an app that will do something similar as piano, but much simpler. It will have 4 tones, that can overlap. I did

1   2   3   4

Sound h0 = TinySound.loadSound("1-H0.wav");         Sound d1 = TinySound.loadSound("2-d1.wav");         Sound fis1 = TinySound.loadSound("3-fis1.wav");         Sound a1 = TinySound.loadSound("4-a1.wav");

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!