IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Fixing ABC/HR Java, Platform dependent wave out
cabbagerat
post May 7 2004, 15:59
Post #1





Group: Members
Posts: 1018
Joined: 27-September 03
From: Cape Town
Member No.: 9042



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?


--------------------
Simulate your radar: http://www.brooker.co.za/fers/
Go to the top of the page
+Quote Post
ff123
post May 7 2004, 16:09
Post #2


ABC/HR developer, ff123.net admin


Group: Developer (Donating)
Posts: 1396
Joined: 24-September 01
Member No.: 12



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

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

ff123
Go to the top of the page
+Quote Post
cabbagerat
post May 7 2004, 18:27
Post #3





Group: Members
Posts: 1018
Joined: 27-September 03
From: Cape Town
Member No.: 9042



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.


--------------------
Simulate your radar: http://www.brooker.co.za/fers/
Go to the top of the page
+Quote Post
schnofler
post May 7 2004, 20:00
Post #4


Java ABC/HR developer


Group: Developer
Posts: 175
Joined: 17-September 03
Member No.: 8879



QUOTE (cabbagerat)
I mentioned this in my mail to schnofler

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

QUOTE (cabbagerat)
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.

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.
Go to the top of the page
+Quote Post
cabbagerat
post May 8 2004, 00:39
Post #5





Group: Members
Posts: 1018
Joined: 27-September 03
From: Cape Town
Member No.: 9042



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

QUOTE
But of course, if you can manage to present me with a usable API and libraries for all the different platforms

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).

QUOTE
or the users would have to install an extra library before using ABC/HR.

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.


--------------------
Simulate your radar: http://www.brooker.co.za/fers/
Go to the top of the page
+Quote Post
rjamorim
post May 8 2004, 00:51
Post #6


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



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.


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
schnofler
post May 8 2004, 09:49
Post #7


Java ABC/HR developer


Group: Developer
Posts: 175
Joined: 17-September 03
Member No.: 8879



QUOTE (cabbagerat @ May 7 2004, 03:39 PM)
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.

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.
Go to the top of the page
+Quote Post
Jasper
post May 8 2004, 10:29
Post #8





Group: Members
Posts: 189
Joined: 9-July 02
Member No.: 2536



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.
Go to the top of the page
+Quote Post
SebastianG
post May 8 2004, 10:56
Post #9





Group: Developer
Posts: 1318
Joined: 20-March 04
From: Göttingen (DE)
Member No.: 12875



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
Go to the top of the page
+Quote Post
caligae
post May 8 2004, 11:18
Post #10





Group: Members
Posts: 186
Joined: 23-January 02
Member No.: 1132



QUOTE (schnofler @ May 7 2004, 09:00 PM)
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.

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.

This post has been edited by caligae: May 8 2004, 11:22
Go to the top of the page
+Quote Post
schnofler
post May 8 2004, 11:47
Post #11


Java ABC/HR developer


Group: Developer
Posts: 175
Joined: 17-September 03
Member No.: 8879



QUOTE (caligae @ May 8 2004, 02:18 AM)
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.
Go to the top of the page
+Quote Post
cabbagerat
post May 8 2004, 12:26
Post #12





Group: Members
Posts: 1018
Joined: 27-September 03
From: Cape Town
Member No.: 9042



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

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.


--------------------
Simulate your radar: http://www.brooker.co.za/fers/
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd October 2014 - 23:11