From the discussion of Roberto's recent aborted 128kBps test it appears as though Java's sound implementation cannot be trusted to give bit-perfect (or near bit perfect) output on some platforms. This is pretty much a prerequisite for ensuring that listening tests are fair and unbiased.

What I want to propose is that we develop several a simple native implementation of the sound operations needed on each platform and interface it with ABC/HR Java. This would be much easier to maintain than, say, a Unix port of ff123's ABC/HR. I have already mailed the relevent parties and would be happy to develop the Linux 'plugin'.

What does everybody think?

Sounds good to me. Here's a multi-platform sound library which might be applicable:

http://www.libsdl.org/index.php

ff123

Thanks ff123.

The first version of my Linux plugin directly talks to OSS (ALSA, the currently preferred option with Kernel guys can emulate OSS very succesfully) but an SDL version will have wider applicability, so I might work on that instead.

I should be able to post a first version tomorrow morning (South African time) and hopefully it can get tested quickly enough to let non-Windows users have access to a completely non-biased platform in time for the next round of testing (probably won't be tested well enough for the 128bit test).

I mentioned this in my mail to schnofler, but I supposed I should say it here. It seems as though this is a problem inherent in the Java platform that can't be solved in Java. ABC/HR-Java is very cool and it would be a major step backwards to replace it.

Could you PM this to me? I haven't received any mail from you.


Well, the obvious problem with this approach is, it breaks platform independence. There would have to be several different versions of the application, or the users would have to install an extra library before using ABC/HR. I definitely don't want to have anything to do with the maintenance of these platform dependent libraries (this is just too much of a pain in the ass).
But of course, if you can manage to present me with a usable API and libraries for all the different platforms, I can make a version of ABC/HR which uses this API.

Sorry schnofler, can you PM me your preffered address? I sent you mail about ten hours ago. Thanks.


I hadn't realised how evil java's JNI is. But I believe by utilising it and SDL I could develop a single library that could compile on any platform that SDL supports (Windows, Linux, Solaris and OSX are included) and offer bit-perfect streaming to the sound card (and access to hardware mixers for gain control).

I agree with you that this is not an ideal solution (or even a good one). If you, or some other Java expert can fix ABC/HR-Java to overcome the limitations of javax.sound then that would be much better. I am by no means a Java expert (did six months of it in first year).


That is the major problem. I was hoping to make the library very small, simple and platform independent so it could be compiled once on a couple of platforms and distributed with the rest of the package. The plain java interface would remain on platforms without a native library installed.

I would really like that solution, if it is feasible. I would hate to give up Java ABC/HR for my tests, since multiplatform support and encryption are major plus compared to ff123's implementation.

In my opinion this is not possible. The loudness issue is unavoidable when using Java Sound, so the only possibility for eliminating it, is using a different library. Since sound playback is inherently platform dependent, and Sun doesn't supply any other sound API with their JDK, there's no way around distributing platform dependent libraries with the application or forcing the user to install an additional library himself.

You may also want to have a look at PortAudio, it supports a lot of APIs and is actively being developed.
http://www.portaudio.com/
I have no experience with SDL, but I've used PortAudio with good results. And it's not that difficult to use, it has both a callback and a blocking API.

hhmm... what is the problem again ?

ok, AFAIK the javax.sound.sampled API makes use of a software mixer which scales the samples down and therefore introduces a bit quantization noise but i doubt that this will affect the outcome of the test since all samples are played back through this API and the q-noise won't be that heavy.

BTW: AFAIK there's an SDL binding for Java that could help. But last time I checked this binding was Linux-only. :-(

bye,
Sebi

Depending on another library isn't really an argument.

E.g. getting Java working on FreeBSD is pretty much a pain in the ass for x86. And it's completely impossible at the moment for other architectures!

Depending on sdl or portaudio would be much less of a burden then depending on Java.

You could also directly talk to OSS. This would reach most of the non-windows users out there. But again, I couldn't find any evidence of OSS support for BeOS for instance.

edit: the only drawback compared to using Java would be that two versions of abchr would have to be maintained.

Well, it's a Java program. If your platform doesn't support Java, you can't run it. Using a different audio library doesn't change a thing. If you want a completely native version for FreeBSD or BeOS you'll have to write it yourself or ask someone who uses these platforms, because I don't.

That's the beauty of schnofler's abchr-java. While Java might be a pain on some platforms it does mean that there is one code base. Which means that results should not be platform dependent in any way. It is also much easier to maintain.

Possibly the ideal solution would be a version using, say, Python and TK but this would mean throwing out the stable and well tested Java version and starting again. I don't think the number of people on non-x86 Unix and BeOS would justify such a move.