[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-sound-dev
Subject:    <Sound Dev> Open question - state of OpenJDK audio
From:       javasound-dev () bome ! com (Florian Bomers)
Date:       2010-10-28 15:08:01
Message-ID: 4CC991D1.7070003 () bome ! com
[Download RAW message or body]

> 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

[prev in list] [next in list] [prev in thread] [next in thread]