From mandolane at mandolane.co.uk Wed Oct 27 15:15:22 2010 From: mandolane at mandolane.co.uk (Mandolane Team) Date: Wed, 27 Oct 2010 23:15:22 +0100 Subject: OpenJDK, Mac OS X and Java Sound Message-ID: <34CB9CA0-E117-402E-BEAD-0D4C5456A4AF@mandolane.co.uk> Dear all As I'm sure you're all aware, Apple recently announced that it is "deprecating" its own version of Java for OS X. This probably means that they will discontinue further development and no longer ship Java with the next version of the OS X (10.7 codenamed "Lion"). As you can imagine, this news has caused great consternation in Mac Java community and huge amount of discussion about what will replace it. Obviously OpenJDK is a top contender for the role. At this point, I admit that I don't know the status of OpenJDK for Macs but I believe that it does not have a Java Sound implementation. The version of Java Sound produced by Apple was pretty pathetic and for a long time it lacked Midi I/O. For these reasons, some years ago we set up a small company to develop an implementation of Java Sound MIDI for OS X, and also an improved and very low latency audio output Mixer for OS X. These were reasonably successful and we had a steady number of sales, plus many customers who wrote to us to say how useful they'd found it. For personal reasons, the company is now in the process of liquidation and it seems a shame to deprive the community of the code we developed if it can be of use. If it would help, then we're prepared to donate all our source code on a free licence open source basis to the Mac port of the OpenJDK project. For the record, we have a working implementation of MIDI I/O and a working audio output mixer. We also have an experimental synthesizer. We don't have an audio input mixer (because there wasn't any demand), we haven't implemented ports, and we haven't implemented our own sequencer. All of our software interfaces to Mac's Core Audio system via JNI. Of course, the project may already have a working version of Java Sound for OS X, in which case we'll consign our stuff to the great software library in the sky! Best wishes Mandolane From mandolane at mandolane.co.uk Thu Oct 28 03:01:06 2010 From: mandolane at mandolane.co.uk (Mandolane Team) Date: Thu, 28 Oct 2010 11:01:06 +0100 Subject: Open question - state of OpenJDK audio In-Reply-To: References: Message-ID: <4D75A04C-BE4C-442B-BA58-87603458A4D9@mandolane.co.uk> Hi Peter and everyone On 28 Oct 2010, at 01:16, Peter Kirn wrote: > Thanks to Mandolane -- the MIDI I/O implementation has long been something needed in Mac Java and would be hugely helpful. This was the spur behind writing Mandolane, although the very latest version of Apple's Java included an implementation of this. Ironically, Apple's version wasn't as good as ours (I would say that, wouldn't I?) and it completely stopped useful side products such as MidiKeys and SimpleSynth from working with Mac Java programs. > > I was also curious about the state of audio in OpenJDK across platforms. I know what was originally proposed, but I'm unclear on the current status of things. It seems to me that what's really essential is MIDI I/O and an audio I/O driver and callback mechanism. JavaSound itself includes many other portions, like the MIDI sequencer, that were never really completed. I wonder whether the OpenJDK project is seriously talking about re-implementing JavaSound, or whether a more future-proof, bare-bones audio implementation is what's really needed. Many years ago, Matthias and Florian explained that the strategy of Java Sound was "make available the facilities of the underlying audio hardware". I have always disliked this idea. No graphics programmer has to worry about the minutiae of the graphics card and monitor: they use an abstract model which the underlying systems convert into images which are displayed on the monitor. Indeed, graphics programming has made the transition from CRT to LCD monitors with zero issues. So (I believe) it should be with audio, but instead we have anarchy. If your program uses a few stereo clips and some stereo continuous sound, and if you're not too bothered with latency then Java Sound is just about adequate. However, if you need low latency then you're dependent on how well the underlying mixer is implemented. Sometimes it's good and sometimes it's not so good. If you're really adventurous (!) and want multichannel sound then for the sake of your sanity don't use Java!! I firmly believe that within the terribly lax specification of Java Sound, it is possible to create a cross platform abstract audio model that will satisfy the requirements of all but the most exacting application. Multichannel set ups include 5.1, 4.0, 7.1, and a few others. I can see no technical reason why we can't write an app for a general multichannel set up and have Java Sound automatically map audio to the underlying speaker system - on ANY platform. If the programmer only has stereo headphones, then a suitable "dummy head" DSP algorithm can be used instead. Rant over ;-) M From dalibor.topic at oracle.com Thu Oct 28 07:17:02 2010 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 28 Oct 2010 16:17:02 +0200 Subject: OpenJDK, Mac OS X and Java Sound In-Reply-To: <34CB9CA0-E117-402E-BEAD-0D4C5456A4AF@mandolane.co.uk> References: <34CB9CA0-E117-402E-BEAD-0D4C5456A4AF@mandolane.co.uk> Message-ID: <4CC985DE.2040500@oracle.com> On 10/28/10 12:15 AM, Mandolane Team wrote: > If it would help, then we're prepared to donate all our source code on a free licence open source basis to the Mac port of the OpenJDK project. Hi, I'd suggest you subscribe to the bsd-dev mailing list, and repost your suggestion there, as that's where the BSD porters are (and the Mac port is part of the BSD port) - I'd guess you'd get a lot of interest, judging by the list traffic. For contributing to OpenJDK in general (and the OpenJDK BSD port, of course), please see http://openjdk.java.net/contribute/ - in particular section "0. Become a contributor". cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | | | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From javasound-dev at bome.com Thu Oct 28 08:08:01 2010 From: javasound-dev at bome.com (Florian Bomers) Date: Thu, 28 Oct 2010 17:08:01 +0200 Subject: Open question - state of OpenJDK audio In-Reply-To: <4D75A04C-BE4C-442B-BA58-87603458A4D9@mandolane.co.uk> References: <4D75A04C-BE4C-442B-BA58-87603458A4D9@mandolane.co.uk> Message-ID: <4CC991D1.7070003@bome.com> > Many years ago, Matthias and Florian explained that the strategy of > Java Sound was "make available the facilities of the underlying > audio hardware". I have always disliked this idea. No graphics > programmer has to worry about the minutiae of the graphics card and > monitor: they use an abstract model which the underlying systems I believe you misunderstood what we meant. At the time (10+ years ago) Java Sound only provided playback through the Java Sound Audio Engine which was severely limited (high latency, 16-bit only, 44.1KHz only, bad conversion for other formats, lowered volume, access only to the default soundcard, etc.). In your analogy that would translate to a graphics abstraction layer that -- for example -- always works on a 16-bit color palette and 1024x768 screen resolution on exactly one monitor. Also note that Java Sound is, of course, an abstraction of the OS' abstraction of the audio hardware. So we never meant to burden the programmer with hardware details. In contrary, we added high-level commands to AudioSystem to make playback easier on any system. What we meant was to make some "basic" features of soundcards available to Java programmers, notably: all available quality modes, number of channels, and all available soundcards, with low latency. And allow the programmer to accurately query the soundcards' capabilities. Enable, but not force, use of more advanced capabilities. The plan was also to add a new high level API for simple sound apps and keep Java Sound as a low level API. That plan never got executed. Regards, Florian > convert into images which are displayed on the monitor. Indeed, > graphics programming has made the transition from CRT to LCD > monitors with zero issues. > > So (I believe) it should be with audio, but instead we have > anarchy. If your program uses a few stereo clips and some stereo > continuous sound, and if you're not too bothered with latency then > Java Sound is just about adequate. However, if you need low > latency then you're dependent on how well the underlying mixer is > implemented. Sometimes it's good and sometimes it's not so good. > If you're really adventurous (!) and want multichannel sound then > for the sake of your sanity don't use Java!! > > I firmly believe that within the terribly lax specification of Java > Sound, it is possible to create a cross platform abstract audio > model that will satisfy the requirements of all but the most > exacting application. Multichannel set ups include 5.1, 4.0, 7.1, > and a few others. I can see no technical reason why we can't write > an app for a general multichannel set up and have Java Sound > automatically map audio to the underlying speaker system - on ANY > platform. If the programmer only has stereo headphones, then a > suitable "dummy head" DSP algorithm can be used instead. > > Rant over ;-) > > M > > > -- Florian Bomers Bome Software everything sounds. http://www.bome.com __________________________________________________________________ Bome Software GmbH & Co KG Gesellschafterin: Dachauer Str.187 Bome Komplement?r GmbH 80637 M?nchen, Germany Gesch?ftsf?hrung: Florian B?mers Amtsgericht M?nchen HRA95502 Amtsgericht M?nchen HRB185574