From mark at klomp.org  Sun May  4 10:19:47 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 4 May 2008 19:19:47 +0200
Subject: <Sound Dev> Opening multiple output lines
In-Reply-To: <48191A17.3070604@redhat.com>
References: <475F1063.6080109@sun.com> <48191A17.3070604@redhat.com>
Message-ID: <20080504171929.GA20060@gnu.wildebeest.org>

Hi Tom,

On Wed, Apr 30, 2008 at 09:17:11PM -0400, Thomas Fitzsimmons wrote:
>>> I'm testing a sound-using applet on Fedora 8.  Sun JDK 1.6 runs the 
>>> appletcorrectly but OpenJDK does not.  The applet attempts to open two 
>>> audio playback lines in succession, without closing the first before
>>> attempting to open the second.
>>> The first open attempt succeeds but the second attempt fails with:
>>>
>>> javax.sound.sampled.LineUnavailableException: line with format 
>>> PCM_SIGNED
>>> 44100.0 Hz, 16 bit, stereo, 4 bytes/frame, little-endian not supported.
>>> [...]
>>>
>>> The exception message is misleading since the line format is 
>>> supported.  The actual cause of the failure is in:
>>>
>>> PLATFORM_API_LinuxOS_ALSA_PCMUtils.c:openPCMfromDeviceID
>>>
>>> This call:
>>>
>>>      ret = snd_pcm_open(handle, buffer,
>>> isSource?SND_PCM_STREAM_PLAYBACK:SND_PCM_STREAM_CAPTURE,
>>>                         SND_PCM_NONBLOCK);
>>>
>>> returns the error corresponding to "Device or resource busy".
>
> Juraj Svec wrote:
>> could you please send some more information? Output of the 
>> TRACE1("Opening ALSA device %s\n", buffer); above the snd_pcm_open would 
>> be great and also your sound card type and version will definitely help.
>
> I've attached the output of running AudioSystemGetLineTest against 
> openjdk-6-src-b09-11_apr_2008 with USE_TRACE defined,
> and the description of my sound card reported by lspci -vv.

I had the same problem with a similar setup and with applications that
forget to close a line they don't use anymore (unfortunately this seems
very common). With the current directaudio backend I don't see how multiple
lines for the same hardware device could work though. So I am using a
trick to look for "sloppy" applications. If the last line opened in the
directaudio device was for the same hardware format then we silence that
one first so we can hand out a new one. This seems to work surprisingly
well. And it doesn't seem to interfere with applications that handle the
hardware formats they need explicitly.

With gcjwebplugin and this patch we can happily play the vNES games :)

Of course a real solution would be to import or write a better mixer
that does share lines properly.

Cheers,

Mark
-------------- next part --------------
--- /home/mark/src/openjdk/jdk/src/share/classes/com/sun/media/sound/DirectAudioDevice.java	2008-04-13 01:05:30.000000000 +0200
+++ openjdk/jdk/src/share/classes/com/sun/media/sound/DirectAudioDevice.java	2008-05-04 18:42:39.000000000 +0200
@@ -394,7 +394,10 @@
         private float leftGain, rightGain;
         protected volatile boolean noService = false; // do not run the nService method
 
-        protected Object lockNative = new Object();
+        // Guards all native calls and the lastOpened static variable.
+        protected static Object lockNative = new Object();
+        // Keeps track of last opened line, see implOpen "trick".
+        protected static DirectDL lastOpened;
 
         // CONSTRUCTOR
         protected DirectDL(DataLine.Info info,
@@ -496,20 +499,47 @@
             // align buffer to full frames
             bufferSize = ((int) bufferSize / format.getFrameSize()) * format.getFrameSize();
 
-            id = nOpen(mixerIndex, deviceID, isSource,
-                       encoding,
-                       hardwareFormat.getSampleRate(),
-                       hardwareFormat.getSampleSizeInBits(),
-                       hardwareFormat.getFrameSize(),
-                       hardwareFormat.getChannels(),
-                       hardwareFormat.getEncoding().equals(AudioFormat.Encoding.PCM_SIGNED),
-                       hardwareFormat.isBigEndian(),
-                       bufferSize);
+	    synchronized(lockNative) {
+	      id = nOpen(mixerIndex, deviceID, isSource,
+			 encoding,
+			 hardwareFormat.getSampleRate(),
+			 hardwareFormat.getSampleSizeInBits(),
+			 hardwareFormat.getFrameSize(),
+			 hardwareFormat.getChannels(),
+			 hardwareFormat.getEncoding().equals(AudioFormat.Encoding.PCM_SIGNED),
+			 hardwareFormat.isBigEndian(),
+			 bufferSize);
+	      
+	      if (id == 0) {
+		// Bah... Dirty trick. The most likely cause is an application
+		// already having a line open for this particular hardware
+		// format and forgetting about it. If so, silently close that
+		// implementation and try again. Unfortuantely we can only
+		// open one line per hardware format currently.
+		if (lastOpened != null
+		    && hardwareFormat.matches(lastOpened.hardwareFormat)) {
+		  lastOpened.implClose();
+		  lastOpened = null;
+		  
+		  id = nOpen(mixerIndex, deviceID, isSource,
+			     encoding,
+			     hardwareFormat.getSampleRate(),
+			     hardwareFormat.getSampleSizeInBits(),
+			     hardwareFormat.getFrameSize(),
+			     hardwareFormat.getChannels(),
+			     hardwareFormat.getEncoding().equals(AudioFormat.Encoding.PCM_SIGNED),
+			     hardwareFormat.isBigEndian(),
+			     bufferSize);
+		}
+		
+		if (id == 0) {
+		    // TODO: nicer error messages...
+		    throw new LineUnavailableException("line with format "+format+" not supported.");
+                }
+	      }
+	      lastOpened = this;
+	    }
 
-            if (id == 0) {
-                // TODO: nicer error messages...
-                throw new LineUnavailableException("line with format "+format+" not supported.");
-            }
             this.bufferSize = nGetBufferSize(id, isSource);
             if (this.bufferSize < 1) {
                 // this is an error!
@@ -616,6 +646,8 @@
             id = 0;
             synchronized (lockNative) {
                 nClose(oldID, isSource);
+                if (lastOpened == this)
+                  lastOpened = null;
             }
             bytePosition = 0;
             softwareConversionSize = 0;

From mark at klomp.org  Thu May  8 17:48:17 2008
From: mark at klomp.org (Mark Wielaard)
Date: Fri, 09 May 2008 02:48:17 +0200
Subject: <Sound Dev> Opening multiple output lines
In-Reply-To: <20080504171929.GA20060@gnu.wildebeest.org>
References: <475F1063.6080109@sun.com> <48191A17.3070604@redhat.com>
	<20080504171929.GA20060@gnu.wildebeest.org>
Message-ID: <1210294097.16656.18.camel@dijkstra.wildebeest.org>

Hi,

On Sun, 2008-05-04 at 19:19 +0200, Mark Wielaard wrote:
> I had the same problem with a similar setup and with applications that
> forget to close a line they don't use anymore (unfortunately this seems
> very common). With the current directaudio backend I don't see how multiple
> lines for the same hardware device could work though. So I am using a
> trick to look for "sloppy" applications. If the last line opened in the
> directaudio device was for the same hardware format then we silence that
> one first so we can hand out a new one. This seems to work surprisingly
> well. And it doesn't seem to interfere with applications that handle the
> hardware formats they need explicitly.
> 
> With gcjwebplugin and this patch we can happily play the vNES games :)
> 
> Of course a real solution would be to import or write a better mixer
> that does share lines properly.

I updated the patch a little to make it all a bit more robust. It splits
the locks, so there is no longer one gaint static one (I shouldn't have
reused the lockNative one and made that static in the original patch).

And it makes sure that all methods that require the nativeLock check the
doIO inside their synchronized block and the lock around nStop() isn't
released before the flag is set. ALSA can actually hang when called on a
pcm you already stopped or closed. This race was already in the code,
since a DataSourceLine could be asynchronously stopped or closed at any
time. My patch just exposed it more easily, because DirectAudioDevice is
the mixer that is now always used by defailt.

2008-05-08  Mark Wielaard  <mark at klomp.org>

        * patches/icedtea-directaudio-close-trick.patch: Use new static
        lockLast for nOpen/nClose guarding.  Make lockNative non-static
        again.  Do all checks before native calls of doIO inside
        lockNative guard. Set doIO to false after nClose before dropping
        lockNative guard.

I do think we should write a new MixerProvider based on a modern
soundserver, like pulseaudio. The current DirectAudioDeviceProvider code
cannot easily be extended to provide true software sound mixing. And the
way it opens direct hardware alsa devices means it locks out other
applications.

Cheers,

Mark

Patch against original code (updated patch file in icedtea6).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icedtea-directaudio-close-trick.patch
Type: text/x-patch
Size: 7732 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/sound-dev/attachments/20080509/6050cf18/attachment.bin 

From kalli at midverk.is  Fri May  9 12:58:51 2008
From: kalli at midverk.is (Karl Helgason)
Date: Fri, 9 May 2008 19:58:51 +0000
Subject: <Sound Dev> Opening multiple output lines
In-Reply-To: <1210294097.16656.18.camel@dijkstra.wildebeest.org>
References: <475F1063.6080109@sun.com> <48191A17.3070604@redhat.com>
	<20080504171929.GA20060@gnu.wildebeest.org>,
	<1210294097.16656.18.camel@dijkstra.wildebeest.org>
Message-ID: <36EC82E93EB0AD40A4301DAD654323868CA4FB2ACD@mail.midverk.is>

Hi,

I added software sound mixing to the gervill Project which writes to default directaudio backend.
And thus allows true sharing of audio device (within the Java application).

cheers,
Karl Helgason
________________________________________
Fr?: sound-dev-bounces at openjdk.java.net [sound-dev-bounces at openjdk.java.net] Fyrir h&#246;nd Mark Wielaard [mark at klomp.org]
Sent: 9. ma? 2008 00:48
Vi?takandi: Thomas Fitzsimmons
Afrit: sound-dev at openjdk.java.net; distro-pkg-dev at openjdk.java.net
Efni: Re: <Sound Dev> Opening multiple output lines

Hi,

On Sun, 2008-05-04 at 19:19 +0200, Mark Wielaard wrote:
> I had the same problem with a similar setup and with applications that
> forget to close a line they don't use anymore (unfortunately this seems
> very common). With the current directaudio backend I don't see how multiple
> lines for the same hardware device could work though. So I am using a
> trick to look for "sloppy" applications. If the last line opened in the
> directaudio device was for the same hardware format then we silence that
> one first so we can hand out a new one. This seems to work surprisingly
> well. And it doesn't seem to interfere with applications that handle the
> hardware formats they need explicitly.
>
> With gcjwebplugin and this patch we can happily play the vNES games :)
>
> Of course a real solution would be to import or write a better mixer
> that does share lines properly.

I updated the patch a little to make it all a bit more robust. It splits
the locks, so there is no longer one gaint static one (I shouldn't have
reused the lockNative one and made that static in the original patch).

And it makes sure that all methods that require the nativeLock check the
doIO inside their synchronized block and the lock around nStop() isn't
released before the flag is set. ALSA can actually hang when called on a
pcm you already stopped or closed. This race was already in the code,
since a DataSourceLine could be asynchronously stopped or closed at any
time. My patch just exposed it more easily, because DirectAudioDevice is
the mixer that is now always used by defailt.

2008-05-08  Mark Wielaard  <mark at klomp.org>

        * patches/icedtea-directaudio-close-trick.patch: Use new static
        lockLast for nOpen/nClose guarding.  Make lockNative non-static
        again.  Do all checks before native calls of doIO inside
        lockNative guard. Set doIO to false after nClose before dropping
        lockNative guard.

I do think we should write a new MixerProvider based on a modern
soundserver, like pulseaudio. The current DirectAudioDeviceProvider code
cannot easily be extended to provide true software sound mixing. And the
way it opens direct hardware alsa devices means it locks out other
applications.

Cheers,

Mark

Patch against original code (updated patch file in icedtea6).

No virus found in this incoming message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 269.23.10/1421 - Release Date: 7.5.2008 17:23




From mark at klomp.org  Sun May 25 12:16:28 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 25 May 2008 21:16:28 +0200
Subject: <Sound Dev> Opening multiple output lines
In-Reply-To: <36EC82E93EB0AD40A4301DAD654323868CA4FB2ACD@mail.midverk.is>
References: <475F1063.6080109@sun.com> <48191A17.3070604@redhat.com>
	<20080504171929.GA20060@gnu.wildebeest.org>
	,<1210294097.16656.18.camel@dijkstra.wildebeest.org>
	<36EC82E93EB0AD40A4301DAD654323868CA4FB2ACD@mail.midverk.is>
Message-ID: <1211742988.3166.43.camel@dijkstra.wildebeest.org>

Hi Karl,

On Fri, 2008-05-09 at 19:58 +0000, Karl Helgason wrote:
> I added software sound mixing to the gervill Project which writes to default directaudio backend.
> And thus allows true sharing of audio device (within the Java application).

This is great! Sorry for the late response. I integrated it into
icedtea. But I haven't set it as default yet because I didn't have time
to fully test it. I do want to have it integrated so others can play
with it though.

Also thanks for your AudioFloatFormatConverter.getTargetFormats() fix, I
removed my own attempt of fixing that. And for integrating the dls/sf2
soundbank opening issues.

Also since we now have jtreg integrated I imported all the tests so they
will now all be run by default on a make check (or make jtregcheck).
That found two issues.

One with a test. TestRender1 accesses its test files through
getResourceAsStream(), but the jtreg tag specification recommends
opening files through the system property test.src so that the test can
be run inside another work directory. See
http://www.openjdk.org/jtreg/tag-spec.txt
Patch to change this attached.

The other issue is with the change that made SoftAudioProcessor
(limiter, reverb, chorus, agc) more general. Since you cannot provide a
Synthesizer directly to one of these classes you need a way to pass it
the control rate. Unfortunately SoftSynthesizer.getControlRate() is
currently protected and there is as far as I can see no other way to get
the control rate. So I believe the method should be made public. A
change to do this and adapt the tests to use this is attached.

With these changes all tests pass.

Cheers,

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestRender1-test.src.patch
Type: text/x-patch
Size: 1370 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/sound-dev/attachments/20080525/5beff035/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: controlrate.patch
Type: text/x-patch
Size: 7079 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/sound-dev/attachments/20080525/5beff035/attachment-0001.bin