So I want to learn how to make a simple sound engine in Java. Any one got any good links for sites that holds a good tutorial for learning it?

I know there's tons of libraries out there for doing it, like paulscode that's posted in this forum, but I really want to learn how to do it myself, I just want something that can play sound effects and continuous music.

It needs more concrete examples, earlier in the tutorial, imho. (There are some in the section on working with various format conversions, about five sections in.) In any event, I think that is a place to start and come back to repeatedly, and I'll be happy to answer questions that come up.

Please be VERY careful playing sound in java. A lot of examples around the interwebs involving play() look good in THEORY, but I've found that they start generating a lot of hanging threads stuck in "ready" state for no particularly good reason. Assuming that you'd like to play WAV sound effects, In my game I created the following function:

This is a bit lower level, but the high level classes seem to have thread issues in some OSs, whereas this logic appears to be stable and run fine in all environments. Basically all I'm doing here is manually spoon-feeding audio data to the audio device. Works well playing multiple sounds in rapid succession with no issues.

Resources should rather be closed in a finally block.playSfx would be more flexible to use if it was just a Runnable and leaving the concrete thread handling to the caller.I would the inner while loop break after the first read failure.

I'd expect to get Mark/Reset errors when dealing with InputStreams. Java7 is much more rigorous about making sure InputStreams are markable & resetable than Java 6 was, and more than a few audio programs broke as a result of the upgrade. wav files generally aren't markable/resetable.

Thus, I'd consider passing in URL's rather than InputStreams, and creating the AudioInputStream directly from the URL rather than the InputStream.

It's beyond my experience to know whether anything is gained by the way you handle the threads. It seems interesting, but I don't understand what you are trying to fix. I've never had problems with lingering audio threads. Other problems, but not that!

Does TinySound do mixing down to a single SDL? I didn't know I was duplicating his wheel. I've also started using a simple mixing algorithm, consolidating down to a single SourceDataLine. It's posted on a neighbor thread with source code.

@nsigma -- One fellow at StackOverflow was suggesting it's better to let the sound mixing occur in hardware, rather than do it up front (as I do). In that case, running multiple SourceDataLines would probably be part of the process. Of course, we've run into systems that only allow one output at a time, so I don't know what this fellow is thinking...maybe thinking in terms of some ideal, or future with sound cards that provide this service. (He also thinks mixing *requires* more complicated math than summation, e.g., an equation such as A + B - AB (where A & B are two volumes between 0 and 1). I'm thinking efforts like this may have their place but aren't strictly necessary.

"We all secretly believe we are right about everything and, by extension, we are all wrong." W. Storr, The Unpersuadables

I haven't ran into anyone having issues with my implementation yet.; I use java 7 yes. The thread hangs any other way I do it -- whatever the reason. And yes, that null check is 1 line too late; I have no idea how it got there :p

Does TinySound do mixing down to a single SDL? I didn't know I was duplicating his wheel. I've also started using a simple mixing algorithm, consolidating down to a single SourceDataLine. It's posted on a neighbor thread with source code.

AFAIK that's what it does - I still haven't actually tried it out I assumed you realised that, as software mixing is mentioned a number of times in the TinySound thread, and you have posted in it ..

@nsigma -- One fellow at StackOverflow was suggesting it's better to let the sound mixing occur in hardware, rather than do it up front (as I do). In that case, running multiple SourceDataLines would probably be part of the process. Of course, we've run into systems that only allow one output at a time, so I don't know what this fellow is thinking...maybe thinking in terms of some ideal, or future with sound cards that provide this service.

Then one fellow at StackOverflow is a muppet! Few cards support hardware mixing, and it's an older feature not a future one. That's why every OS now has a sound server that does mixing in software. If you have a system that supports multiple SDL's then it's almost certainly mixing in software, just outside Java. This is an inefficient way of outputting multiple sounds from a single application - it's primarily designed for allowing multiple applications to output audio at the same time.

(He also thinks mixing *requires* more complicated math than summation, e.g., an equation such as A + B - AB (where A & B are two volumes between 0 and 1). I'm thinking efforts like this may have their place but aren't strictly necessary.

The guy seems to be proving he's an idiot. Be interesting to see the link exactly - found that equation linked to in an article that talks about combining sounds without clipping. It presumably acts like a limiter to stop the sound peaking, but it must cause some distortion at higher levels. A better approach is something like the automatic gain control used in JASS (http://www.cs.ubc.ca/~kvdoel/jass/) that tracks the highest output and reduces all values (not a sample at a time) to keep within range. I adapted that in some old code using JASS so that the maximum value reduced slightly over time (a few seconds) so that a short peak wouldn't cause everything to become quiet permanently - closer to the behaviour of a proper limiter. It's a better approach to avoiding clipping.

Does TinySound do mixing down to a single SDL? I didn't know I was duplicating his wheel. I've also started using a simple mixing algorithm, consolidating down to a single SourceDataLine. It's posted on a neighbor thread with source code.

AFAIK that's what it does - I still haven't actually tried it out I assumed you realised that, as software mixing is mentioned a number of times in the TinySound thread, and you have posted in it ..

I assumed that the TinySound library was creating wrappers, using multiple output lines. PaulsCode does the same, doesn't it? Why else did he start out on a separate project to make a mixer (yet uncompleted afaik)?

In any event, I really do need to find the time to look at the code behind TinySound, and set it up an run it.

I assumed that the TinySound library was creating wrappers, using multiple output lines. PaulsCode does the same, doesn't it? Why else did he start out on a separate project to make a mixer (yet uncompleted afaik)?

Here's the link to the StackOverflow question:...You probably have some good advice and recommendations for the fellow's main question (the system you wrote or coauthored, I'm thinking).

The guy's quite amusing - suggesting using FFT to mix audio. And the idea that Java isn't fast enough to mix a few sounds together is hilarious. I've been using Java for DSP for almost 10 years now. People have written entire sequencers and softsynths in pure Java - http://youtu.be/9sYGcziGtHI

I'd just forget all that crap and figure out OpenAL using LWJGL or JogAmp.

(See also discussions on Java2D vs OpenGL)

Not really a correct comparison, though. OpenGL is direct access to a hardware accelerated (and programmable) graphics pipeline. OpenAL is a fairly limited API, and presumably in most cases running on top of the platform's primary audio system? The low-level bits of JavaSound also give direct access to the native audio system, so it's possible to achieve far more scope and flexibility using it (or alternative bindings like PortAudio) and programming audio code in Java itself. Most people on here should take the advice to use a library, be it OpenAL, TinySound, etc. It really depends what features you require now and in the future, but I'd tend to prefer things written in Java as it's easier (possible) to get in and fiddle with the code if you ever need to. Just ignore Clip and all the code posted above!

And seems like there's almost as much dispute over how to handle sound as to j2d vs opengl. Though I'm slowly coming to terms with a thought that keeps creeping up in my mind... "Just use LWJGL/LibGDX/OpenAL and be done with it!"....

PaulsCode does the same, doesn't it? Why else did he start out on a separate project to make a mixer (yet uncompleted afaik)?

PaulsCode does not include a software mixer last I checked. Instead, it's just an abstraction of different sound libraries -- LWJGL, JOGL and Java2D. TinySound, on the other hand, mixes all channels in software into a single JavaSound clip (if I remember correctly).

Regarding Paul's 3D sound library -- IMO it's not the best.

OpenAL just sounds different than Java2D. This is obvious when you run the same audio file through the two different libraries. Java2D has crackles, pops, and glitches -- especially when stopping a cilp -- and often leads to slightly different volumes. So you might have fine-tuned your game to the LWJGL backend, but then testing it with the Java2D backend everything might sound a little off. And then you begin to question why you have a Java2D backend in the first place...

The reason Paul went lengths to abstract sound is for "maximum compatibility" -- but realistically if your user doesn't support OpenAL, they probably won't be able to run your game!

So why bother with the Java2D backend at all? Then you are left with only two: JOGL or LWJGL. Obviously if your game is based on LWJGL, it makes no sense to use a JOGL backend, and vice versa. So really you just have a huge, clunky, multi-threaded and IMHO poorly designed API that wraps LWJGL.

With that said, Paul has written some fantastic decoders that are not very dependent on the rest of the library.

Quote

"Just use LWJGL/LibGDX/OpenAL and be done with it!"...

For a beginner, it's easier to just use a wrapper: TinySound, Pauls Sound System, LibGDX, or even SlickUtil if you must.

Arh, but I want to use OpenGL for my game, so I might as well use the stuff that libraries like LJWGL offers. (I started making my game in pure java2d, but it started dropping frames when placing more than 100 towers xD)

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