(basically just adding amplitudes of each sample correct?)
Yes, but don't forget to divide the amplitudes by the number of channels too, to prevent clipping. Best to do this *after* adding all channels, not before. You will get noise if you divide the amplitudes before mixing.
But maybe you won't need to mix everthing yourself. In my case, I emulate sound chips, and I use one sourcedataline per chip, but mix the channels of each chip myself. For a game I guess it's another story. But I still think you shouldn't have separate threads for each SourceDataLine, which was my main point.
But won't there be problems in the playback if the next game frame took even a little longer (buffer underflow), or shorter, than the supposed 10ms?
I guess you could do some buffering to prevent this, although I do believe there is already some buffering before the data actually goes to your sound board.
But if you do need to implement buffering, maybe you could set some target amount of latency based on how much you expect the framerate to vary. So the first frame you could fill the buffer until the target latency would be reached, then you fill the buffer with the number of samples needed for each frame (like we discussed). If the next frame will take longer, you won't get buffer underruns except if that frame will take longer than the set amount of latency. (I don't know if this is the best implementation, just thinking out loud here)
In my code I simply rely on the game (well, actually an emulator) to run exactly the correct amount of FPS which of course makes things way more easy, which is why my source won't be all that helpful to you.
But like I said, I think there's already some buffering going on (inside javax.sound or maybe in the sound driver, I'm not sure), so maybe this extra buffering isn't even necessary (I never experienced any buffer underruns in my emulator at all yet, which doesn't implement buffering at all).
Arrgh! Grappling with javax.sound to make it work properly is needlessly tedious indeed...
Heh, I actually find javax.sound a pretty convenient and straightforward API :-) I think you might have had this kind of problems with any other sound API as well as I believe the multiple threads are the cause of your problems.