Awesome, thanks. It’s really nice to hear that people are actually using TinySound.
I’ve been using this in a couple of games of mine, that i’ve only tested on my computer. I sent it over to my friend for testing and when it came time for sound, he got [this error][/http://i.imgur.com/Tqrq9.png?1]. Any idea what happened?
Hmm, It looks like you may be using an older version of TinySound than is currently in the repository. It appears to be failing to convert the audio format of the sound files, and I definitely fixed a bug related to that relatively recently that was dependent on the version of Java you have installed.
I am using an older version, but it works fine on my computer, but not theirs, does it have something to do with audio drivers or something like that?
It can depend on drivers, but it can also depend on the version of the JRE that they are using. Regardless, I would still recommend using the most recent version as the bug seemed like it would be problematic in a good number of cases.
So I tried this because I am newbs at sound and first thing I get is out of memory errors. I had my VM set to 32m which is lower because I am trying to make sure I do not hog mass amounts of memory. I had to bump it up to 256m and the program now sets at around 132m. Is this normal for sound? Seems like a huge jump just for a few sound files. (3 to be exact).
TinySound doesn’t do any intelligent loading/unloading or streaming of audio. It just loads the entire audio file into memory and keeps it there until you call unload on the Sound/Music or until you shutdown TinySound. The amount of memory each file takes up is almost exclusively dependent on its length, as TinySound converts all audio to 16-bit, linear PCM audio at 44.1khz sample rate. You can save memory if your files are mono as opposed to stereo, but even compressed formats (such as ogg-vorbis) are converted when loaded into memory, so you only save disk space with those.
As a quick and dirty workaround, you should uncompress the audio files to the temp-dir, and stream those uncompressed files. This prevents unacceptable memory usage for long audio.
Streaming audio is definitely something I’ve thought of adding to a future version of TinySound. I’ve opened an issue on the repository to remind myself.
Hello. Im tryng to use tinysound,im using a compiled version from your repository. Seems to work really fine till now, thanks for the effort.
How can i use it to load OGG ?
Thanks for your attention !
In order to load OGG Vorbis files, you’ll need to include the other jars located in the lib directory in your classpath. That is, you need to include tritonus_share.jar, jorbis-0.0.17.jar, and vorbisspi1.0.3.jar in your classpath. If you’re using an IDE like Eclipse, you can just reference them in your project the same way you did with tinysound.jar.
If you got the streaming working you would be my hero and I would bake you a cake ;D…it may go bad in the mail tho.
Just want to say keep up the fantastic work.
Haha. Well, I’m already working on it. I can’t make any promises, but I should have a good chunk of time to work on it on Sunday.
This works nicely!
But i’m noticing little random cracks in the background while the ogg plays, which doesn’t happen when i’m using the LWJGL backend.
EDIT: It is really random. But it only seems to happen on 128kbps ogg files. I re-encoded the original mp3 file to 112kbps and 160kbps. No cracks on both!
YAY!
I’m glad that’s working. Still, it is odd that it was cracking. There are two places that I can think of where the cracks would be introduced: 1) In TinySound’s update thread writing to the speakers, or 2) in the conversion code from Ogg-Vorbis to linear PCM. Given that it was fixed when you changed the encoding, it was probably the latter. If so, it takes the blame off of TinySound and puts it somewhere in the other jars, but that would also mean there is nothing I can do to help.
I did a bit of redesign and refactoring to add the ability to stream audio data from a file. I haven’t tested it much, but it seems to be working so far. There’s still a bit of work for me to do, but I have the new version on a separate branch.
Give it a try if you like. It takes a long time (read: very long time) to write the audio to a temporary file, and I’m not entirely sure why that is yet, but I’ll keep working on it whenever I have the time.
So I have tested your new code and yes the load time is very very…very long but unfortunately it still uses almost the exact same amount of memory. I am not sure if I am doing something wrong but not a huge change. 160m-180m to 160m :clue:
Keep working on this as I am a nub at sound processing right now and this would be a great library for simple games.
Well, it still loads everything into memory for conversion before writing out to a temporary file, so it’s possible the garbage collector hasn’t kicked in. I just saw the same thing with a test of my own, but when I put a call to the garbage collector after my loading code, it reduced memory usage dramatically.
Well, I fixed the load time at least. I thought FileOutputStream was buffered, but I guess it’s not. Wrapping that with a BufferedOutputStream dropped my test load time from almost two minutes to under ten seconds.
[quote]Well, I fixed the load time at least. I thought FileOutputStream was buffered, but I guess it’s not. Wrapping that with a BufferedOutputStream dropped my test load time from almost two minutes to under ten seconds.
[/quote]
Sweet! ;D Did you at that to a revision I could test?
I thought it might be a garbage collector thing but sometimes you just never know.
Edit:
Tested it and yes loads fast now. With lots of sound files (which I intend) it could get lengthy but nothing a loading screen could not fix.
The memory is lower as in I can drop the heap size down to 128m and it sits at 110m-120m but System.gc() does nothing so 
I don’t know how to force a GC and I don’t even think you can. I know that it will have to have a heap big enough to load what ever your largest sound file is.