From mark at klomp.org  Mon Nov 10 03:45:48 2008
From: mark at klomp.org (Mark Wielaard)
Date: Mon, 10 Nov 2008 12:45:48 +0100
Subject: [Audio-engine-dev] New Gervill CVS imported into IcedTea6
Message-ID: <1226317548.3527.24.camel@dijkstra.wildebeest.org>

Hi,

I updated the IcedTea6 Gervill overlay with current Gervill CVS.

Out current set of changes compared with upstream are now really minimal
(diff attached). It incorporates a couple of the fixes for the
unloadInstruments methods from icedtea. It also fixes an imported bug
reported against icedtea "freezes on simple midi app":
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=213

Also since openjdk6 imported a newer Gervill and incorporated a couple
of the changes in the icedtea gervill not yet upstream, we are a bit
closer again. diff between icedtea6-openjdk6 attached. Some of this is
just reformatting changed done in the openjdk6 on the upstream sources.
Not included in the diff is the renaming/changes to the upstream tests
(most of which are similar to our and upstream tests, but repackaged and
slightly reformatted).

All jtreg tests, both the com/sun/media/sound ones from upstream, as the
older javax/sound/midi in openjdk6 (which are almost all a copy of the
upstream tests renamed into a different package) pass.
And you can run them with the new jtreg -s flag, which gives an enormous
speed boost! That is in 45 seconds. Compared to 4.5 minutes without -s.
Test results: passed: 475

2008-11-10  Mark Wielaard  <mark at klomp.org>

        * overlays/openjdk/jdk/src/share/classes/com/sun/media/sound/
        CHANGES.txt,SoftAudioPusher.java,SoftFilter.java,
        SoftJitterCorrector.java,SoftMainMixer.java,SoftVoice.java:
        Updated to new Gervill CVS.

Changes to the icedtea overlays since last import attached.

The actual changes to Gervill since our last import:

- Fix: Throw IllegalArgumentException Exception on
       invalid soundbank to:
       SoftSynthesizer.unloadAllInstruments(Soundbank soundbank)
       SoftSynthesizer.unloadInstruments(Soundbank soundbank, Patch[] patchList)
       just like done in:
       SoftSynthesizer.unloadInstrument(Instrument instrument).
- Change: SoftMainMixer, SoftVoice optimized for mono voices.
- Change: SoftFilter optimized. 
- Fix: Turn SoftJitterCorrector, SoftAudioPusher threads into a daemon threads.
       These threads prevented the VM to exit when synthesizer was open.
       See: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=213 

Cheers,

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gervill-icedtea.diff
Type: text/x-patch
Size: 2643 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/audio-engine-dev/attachments/20081110/b65d818e/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icedtea-openjdk.diff
Type: text/x-patch
Size: 10415 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/audio-engine-dev/attachments/20081110/b65d818e/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gervill-overlay.patch
Type: text/x-patch
Size: 12746 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/audio-engine-dev/attachments/20081110/b65d818e/attachment-0002.bin 

From wbrown at colorfulsoftware.com  Thu Nov 20 19:04:50 2008
From: wbrown at colorfulsoftware.com (Bill Brown)
Date: Thu, 20 Nov 2008 21:04:50 -0600
Subject: [Audio-engine-dev] Issue with AudioSystem.getSoundbank() plus
	proposed patch.
Message-ID: <2c580c790811201904i52dacbb4t610fbfc8ba6bdaa2@mail.gmail.com>

Greetings Audio Devs:

I did not find this issue discussed previously in the archives.  I have run
into an issue with the current Openjdk implementation of
AudioSystem.getSoundbank() that applies to all three variants File, URL and
InputStream.   The current implementation only considers the first valid
javax.sound.midi.spi.SoundbankReader  instead of checking the Soundbank
instance for use with the loaded or default Synthesizer.  This consideration
is arbitrary based on the order in which the SoundBankReader implementations
are made available and my be wrong when there are multiple providers for
different synths that handle the same file type / format.

The Soundbank returned from the method is only useable by a Synthesizer (the
currently loaded Synthesizer) and each Synthesizer's soundbanks are unique
for that synthesizer by design (
http://www.j2ee.me/j2se/1.3/pdf/javasound.pdf  section "Providing Soundbank
File-Reading Services" p. 148).    My current project (code named EMAP)
provides a SoundbankReader for the same .sf2 file type as Gervill.  This
current MidiSystem.getSoundbank() breaks my app and have not figured out a
workaround that doesn't involve the proposed patch.

Because it is possible to enforce which Synthesizer is used by setting the
system property javax.sound.midi.Synthesizer, it should be possible to load
a soundbank from a file that is supported by the loaded Synthesizer.  Here
is a patch suggestion that can somewhat handle this request without adding a
big implementation change:


public static Soundbank getSoundbank(File file) //can be used also for the
URLand InputStream signatures
        throws InvalidMidiDataException, IOException {
                SoundbankReader sp = null;
                Soundbank s = null;
                Soundbank validSoundbank = null;

                List providers = getSoundbankReaders();

                for(int i = 0; i < providers.size(); i++) {
                    sp = (SoundbankReader)providers.get(i);
                    try{
                        s = sp.getSoundbank(file);
                    }catch(IOException io){}
                    catch (InvalidMidiDataException ime){}

                   if( s!= null) {
                        //crosscheck support with the current default
synthesizer.
                        //because the soundbank is not much use otherwise.
                        //there may be more than on synth in the system
                        //that supports this file format.
                        try{
                            Synthesizer synth = (Synthesizer)
                            getDefaultDeviceWrapper(Synthesizer.class);
                            if(synth.isSoundbankSupported(s)){
                                return s;
                            }
                            //still arbitrary at this point but at least we
have
                            //checked against the default synthesizer.
                            validSoundbank = s;
                        }catch(MidiUnavailableException e){}

                    }
                }
                if(validSoundbank != null){
                    return validSoundbank;
                }
                throw new InvalidMidiDataException("cannot get soundbank
from stream");
    }


I think the API would be more robust if it could handle the scenario where
there are multiple providers that can handle the same file type.  I think
the extra overhead that this patch creates is small compared to the
usefullness of being able to get a handle on a Soundbank that will work with
the currently loaded Synthesizer.  Another way to handle this issue could be
to add signatures and implementations in the API to allow a Synthesizer to
load a Soundbank in the same manner as the MidiSystem.  But it you did that,
I don't see much use for the MidiSystem versions.

Please consider this patch, or something like it,  for inclusion to the
openjdk implementation or possibly provide some workaround for loading a
useable Soundbank when there are multiple synths in the system that support
the same format.

Thanks for looking at this..
Bill.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/audio-engine-dev/attachments/20081120/89375f08/attachment.html