Selecting non-default Mixer

[kuusisto]

@nsigma

@kuusisto

It sounds like the most appropriate solution is to just add a second init() function which takes a Mixer.Info, so the user can specify which Mixer to use. I’ll, of course, leave the current init() function in as well, which uses the AudioSystem.getLine() function.

I’d say yes to the two init functions, but use the first mixer that supports outputs by default. Using a line from AudioSystem.getLine will get you lousy performance in some cases, particularly on Linux. This is because AudioSystem looks for mixer capable of playing multiple lines, so ignores the direct mixers because they can only use a single line. As you’re doing software mixing, you want to benefit from the better performing mixer by default.

That’s reasonable. Thanks for all your help and advice.

[nsigma]

Quick follow up (I was replying on my phone before) to back up my previous point.

You can see the code in OpenJDK that implements getLine() here (line #407). Notice how it searches for a default mixer set through system properties, then one capable of opening more than one line, and then finally one that can only open a single line - hence the behaviour mentioned above. I wonder whether you should take notice of whether the system property is set, but would probably leave that to the users of your library to decide.

Incidentally, if you haven’t already found it, http://www.jsresources.org/ is a useful site. It’s not been updated for a long time, but it’s still mostly relevant information.

[gouessej]

@nsigma

Your usual advice to ignore JavaSound and use OpenAL is only useful for some, and only useful if people are happy / able to use additional native code. It’s throwing the baby out with the bathwater. You’re not helping people avoid headaches - you’re giving them one! :

One time again you misquote my comments. JavaSound is difficult to use as is with its limitations and the bugs around it (or in it in some cases) and you’re unable to admit that fact. Moreover, you know that OpenAL is easy to use with Paul Lamb Sound Library. I don’t throw the baby out with the bathwater, I use JavaSound as a fallback. I don’t add native dependencies for the pleasure of doing so. You don’t really make me laugh, I’m fed up with this behaviour consisting in constantly laughing about my comments when there is a disagreement. I’m aware of the fact that using native code is not always possible, that’s why it is important to remind some “common” problems occurring with JavaSound. I don’t see how such reminders may give headaches to anyone and I find your reaction quite inappropriate. kuusisto may succeed in doing something fine with JavaSound and I think knowing these “common” problems is a real advantage. Anyway, I agree with your very last suggestion and such an information is precious especially if kuusisto rarely tests his library under GNU Linux.

[nsigma]

@gouessej

@nsigma

Your usual advice to ignore JavaSound and use OpenAL is only useful for some, and only useful if people are happy / able to use additional native code. It’s throwing the baby out with the bathwater. You’re not helping people avoid headaches - you’re giving them one! :

One time again you misquote my comments. JavaSound is difficult to use as is with its limitations and the bugs around it (or in it in some cases) and you’re unable to admit that fact.

Way to follow a misquote with a misquote! You’re completely misunderstanding my position here, as you did about JNA recently. JavaSound is a horrible API, has lots of bugs, and some real gotchas working across platforms. It’s also possible to work around those and make use of it when necessary. One of the aims of the JAudioLibs project is to hide the workarounds in a common API, and one that works with other native backends too - I’ve nothing particular against native audio libs, and wrote the only active binding to JACK.

@gouessej

Moreover, you know that OpenAL is easy to use with Paul Lamb Sound Library.

No idea, as I don’t make use of OpenAL as it’s not particularly suitable for my uses. I have some misgivings about the code I’ve seen (mainly due to use of synchronized sections) but generally it seems useful. As will TinySound be - something that’s been needed around here for a long time!

@gouessej

You don’t really make me laugh, I’m fed up with this behaviour consisting in constantly laughing about my comments when there is a disagreement. I’m aware of the fact that using native code is not always possible, that’s why it is important to remind some “common” problems occurring with JavaSound.

If you think I’m laughing at your comments, you’re mistaken. I’m not trying to get your back up, and I think you’ll find I have a lot more respect for your views than you think. However, I am (mildly) annoyed that you have consistently ignored the links I’ve sent you or the offers to help get to the bottom of this. Reminding people of “common” problems is helpful; being able to tell them how to work around them is more so!