Memory Usage------------The basic loading functions for Music and Sound objects produce implementationsthat store all audio data in memory. This is good for maintaining low latency,but can also require a lot of heap space if you load many, or particularly long,audio resources. There are loading functions available that allow you torequest that the audio data be streamed from a file. If this is requested, theaudio data will first be converted as usual and then written to a temporary filefrom which it will be streamed. This will dramatically reduce the overallmemory usage (after loading), but can potentially introduce occasional latencywhen reading from disk.

This is the latest code, for music only. I switched streaming from file or not (true/false in snd declaration) and the difference was around 3 megabytes. Switching between Sound and Music also makes no difference. It really bothers me when I see VLC using 11 megabytes only while playing them

Again, sorry I haven't been on in a while. I've been crazy busy with my academic life.

What TinySound does when streaming is it first loads the whole thing into memory to convert to the correct format, writes it to a temporary file, and then streams that. It can thus end up using a lot of memory at loading time, but that should be drastically reduced when streaming. Now, depending on how you monitor memory usage, it can still appear to be using a lot more memory. If you just look at how much memory the JVM has been allocated (e.g. the Task Manager on Windows, or top on Linux), it will be large. This is because it needed that memory at some point. The actual heap space in use when streaming, however, should be much lower. You can tell how much memory is actually in use with something like:

It probably isn't. After you added the streaming I did what you said kuu and the memory usage is basically 40-50 mb which is fine even thought it says 200+. I still think this lib is great for how easy it is to add sound with ogg support to a game or app.

Well, using mbInUse actually made me see the difference of 160 to 240 but I believe that it's still stupidly high

That is high. Can you post all of the code you're testing with?

Edit:I just took your code that you most recently posted and added the minimum amount required to get it running. I see what you mean about the memory usage, but it appears to be a result of the fact that you load and unload the Sound on each iteration. When I added a

1

System.gc();

right before the sleep, I was seeing less than 1MB of memory usage at the end of each iteration. The moral of the story is that you shouldn't load and unload so much. If you're going to use some music, load it and store it somewhere until you're done with it. If you're using the streaming implementation, the Music object itself should take up very little memory, so there's no reason not to hang onto the reference.

During the last years I have tried several solutions for audio in Java games, including the stock JavaSound classes, the JavaZoom libraries, and Paul Lamb's sound system. But I find the same problem in all of them: under Windows everything works fine, but under Linux (or at least for some distributions/java versions), simultaneous sounds don't work. You want to play an effect at the same time as music, crash. I have spent many evenings googling about this, but there are contradicting explanations on the internet and to be honest I don't know a word about pulseaudio, mixers, sound drivers, etc. I'd just like to focus on the gameplay and have the audio work like in Windows :/

The only solution I know to work is to use stuff like OpenAL but this requires distributing native code, and I wouldn't like having different distributions of games depending on the OS.

Is it known whether this library addresses that issue (in pure Java) or it also has that shortcoming? If it does address the issue, I think I'm going to switch to it in no time...

TinySound should work fine on Linux because it mixes all audio to a single line. This was actually one of the problems that I was trying to address when I created TinySound. I did once observe a latency issue with some drivers that I had installed, but others might be able to comment on their experiences.

Any library that does software mixing (like this one) will work fine on Linux. There are a variety of reasons multiple sounds don't work or don't work well on Linux when using JavaSound the way Paul Lamb's system and others do. Even on Windows it's not a great way to work, constantly getting JavaSound to open and close multiple lines to the soundcard - that's not how to write any audio software, and just because you can get away with it on Windows don't assume that's the way it works cross-platform.

The upside ... pick a good library that does mixing in Java and you will get generally get better performance on Linux than Windows.

I've been trying to get sound working with various libraries and TinySound seems to be the best for me to use at the moment. It's been working great but when I profiled my program the memory being used went from it's usual 10mb and kept increasing over time. After coming to this thread and briefly scanning over a few pages I noticed people saying that the StreamSound/StreamMusic might lower the amount of memory used because the audio files won't be loaded into memory.

I, for some reason, was unsuccessful in attempting to get StreamMusic/StreamSound to work. Could someone look over the code below and tell me what I should chnage to get it to work.

@tyeeeeee1I don't understand. Did you or didn't you separate the loading from the play as suggested by cubus?

The code that you displayed still has the two together in a single call. Each time you load the file you will burn more memory as you store yet another copy in RAM. That is why the play() method should NOT be in the same method with the loadMusic() method.

@tyeeeeee1I don't understand. Did you or didn't you separate the loading from the play as suggested by cubus?

The code that you displayed still has the two together in a single call. Each time you load the file you will burn more memory as you store yet another copy in RAM. That is why the play() method should NOT be in the same method with the loadMusic() method.

Derp... Guess I had the half-updated code in my CnP and didn't notice. Yes, I separated both of them, here is what the code actually looks like:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

privateMusicmusic;publicAudioHandler() {//initialize TinySoundTinySound.init();//load a sound and music//note: you can also load with Files, URLs and InputStreamsURLurl = this.getClass().getClassLoader().getResource("Resources/Sound/MainMenu.mid");music = TinySound.loadMusic(url, true); }

publicvoidplay() {music.play(false); }

It's still using the same amount of RAM as before the change though. The '.mid' file that I'm using is only 2kb.

Edit: I accidentally left the program open for a few minutes and noticed that it eventually drops back down from 50mb to 25mb so I'll assume I shouldn't care too much about the RAM anymore then.

does the memory usage grow, or is it just as before?that's what i was pointing out in the first post: TinySound loads the _whole_ audio data and stores it in a temp file, from which it then streams.

i tried the code now. you must call music.rewind() before music.play() to replay it.

the only memory it allocates when replaying is in setPosition() which gets called from rewind(), coz this closes the stream and reopens it. (i don't know why it is implemented this way, since it creates the temp file, which i thought gets created to have a resetable input stream...)

does the memory usage grow, or is it just as before?that's what i was pointing out in the first post: TinySound loads the _whole_ audio data and stores it in a temp file, from which it then streams.

i tried the code now. you must call music.rewind() before music.play() to replay it.

the only memory it allocates when replaying is in setPosition() which gets called from rewind(), coz this closes the stream and reopens it. (i don't know why it is implemented this way, since it creates the temp file, which i thought gets created to have a resetable input stream...)

When I first start the program it's at the usual 10mb and then within seconds it grows to 40mb and by the end of the mid file, which is a few seconds long, it stops around 50mb then after a while longer it drops from 60+mb to 20mb and starts growing up to around 70mb and repeats the cycle. I've noticed that if I leave the file on loop it does the same thing.I'm starting to think that there is something in the rest of my program that is causing the memory to grow or something.

Cubus, I'm wondering if the info you are giving is correct. Usually it is a "Clip" type structure that has the position reset feature, not a streaming structure (e.g. SourceDataLine in java audio terms).

I would like to suggest changing .loadMusic() in your updated example to .streamMusic().

I *think* that loadMusic() functions like a Clip, loading the entire file to memory, and allowing looping and position setting. And streamMusic() functions like a SourceDataLine, allowing streaming without loading any more than a single buffer's worth of sound data from the file at a time.

According to NetBeans ".streamMusic()" doesn't exist. I was originally trying to set up streaming but I couldn't get it to work due to a lack of examples of how to use TinySound.I just tried removing the two lines that use the AudioHandler class and used memory, when profiling, never grows beyond 20MB. The two lines that I use are:

I just did a quick build of my program to check if the audio is actually streaming. From what I read on the link that cubus just linked:

Quote

Memory Usage------------The basic loading functions for Music and Sound objects produce implementationsthat store all audio data in memory. This is good for maintaining low latency,but can also require a lot of heap space if you load many, or particularly long,audio resources. There are loading functions available that allow you torequest that the audio data be streamed from a file. If this is requested, theaudio data will first be converted as usual and then written to a temporary filefrom which it will be streamed. This will dramatically reduce the overallmemory usage (after loading), but can potentially introduce occasional latencywhen reading from disk.

I should, assuming that the file being created is created in the same folder as my .jar is, see the file that the data is being streamed from. After doing the test and letting it run for a while I never noticed nor saw any file being created on the startup of my .jar so I'll assume that both ".loadMusic(url, true)" and ".loadSound(url, true)" aren't telling it to stream the music.Is there another way to tell TinySound to stream the music other than this way and the other way that I first tried which didn't work?

Found it, looks like the streaming is working properly then. I wonder what could be causing 40mb of ram to be used then since my program runs on a max of 20mb without TinySound being used at all. Is 40mb just for TinySound normal or...?

Edit: Also, are the temp TinySound files supposed to be deleted? I have around 15 5mb files in my temp folder just for it.

I have 1.82 GB of undeleted TinySound garbage. I feel like maybe deleting the files wasn't originally accounted for in the source? If so, you (kuusisto) should implement a basic scanner to scan for old undeleted files and delete them, like in this code bit:

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