[Bug 1304] New: After first sound made, CPU continues to be used by pulseaudio thread even though idle

[bugzilla-daemon at icedtea.classpath.org]

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1304

            Bug ID: 1304
           Summary: After first sound made, CPU continues to be used by
                    pulseaudio thread even though idle
    Classification: Unclassified
           Product: IcedTea
           Version: 2.3.3
          Hardware: x86_64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: PulseAudio
          Assignee: omajid at redhat.com
          Reporter: ajvok1 at gmail.com
                CC: unassigned at icedtea.classpath.org

Make a simple beep sound via pulseaudio.
Even if program then completely idle, it continues to consume some CPU.
This appears to be caused by the pulseausio thread.

If I find the pulseaudio thread and suspend it after making the beep, the CPU
use stops. I can then resume the thread before the next beep.
But that uses deprecated 'suspend()' and 'resume()', so not good.

Another approach is to interurpt() the the pulse thread.
That cause the thread to die, which does prevent further CPU use.
But the second beep results in:

java:
/build/buildd/openjdk-7-7u9-2.3.3/build/../pulseaudio/src/native/org_classpath_icedtea_pulseaudio_Stream.c:319:
Java_org_classpath_icedtea_pulseaudio_Stream_native_1pa_1stream_1new: Assertion
`context' failed.
A can see no obvious way of then using pulse again after I've interrupted it
like this.

A quick look at the pulseaudio code suggest to me that the culprit the call to
native_iterate(100);  in EventLoop.run().
There appear to ne no way to completely shutdown activity on the pulse thread
between uses (without my nasty use of suspend/resume).

Is this:
a) Me missing something? or;
b) a bug? or;
c) a feature that is missing?

It seems silly to have a thread handing around using CPU when I only use it fo
a beep evry few minutes (or even hours).

Any help much appreciated. Thanks.

java version "1.7.0_09"
OpenJDK Runtime Environment (IcedTea7 2.3.3) (7u9-2.3.3-0ubuntu1~12.10.1)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

Same on similar 32 bit version.

I started with this:

public static void beep1(int hz,int msecs) {
  try {
    // Borrowed from somewhere on the web. Apologies to the author for not
providing a link. Lost it.
    byte[] buf = new byte[msecs*8];
    for (int i=0; i<buf.length; i++) {
      double angle = i / (41000.0 / hz) * 2.0 * Math.PI;
      buf[i] = (byte)(Math.sin(angle) * 80.0);
    }
    AudioFormat af = new AudioFormat(44100.0F,16,2,true,false);
    SourceDataLine sdl = AudioSystem.getSourceDataLine(af);
    sdl.open(af);
    sdl.start();
    sdl.write(buf,0,buf.length);
    sdl.drain();
    sdl.close();
    sdl.stop();
  } catch (Exception e) {
    e.printStackTrace();
  }
}

public static void main(String[] args) {
  try {
    beep1(700,20000);
    Thread.sleep(60000);
    beep1(700,20000);
  } catch (Exception e) {
    e.printStackTrace();
  }
}

After the first beep, CPU continues to be used, even though the program is
apparently idle.

Attempting a workaround, I then add:

private static Thread pulseThread ;

public static void beep2(int hz,int msecs) {
  try {
    if (pulseThread!=null) pulseThread.resume();
    beep1(hz,msecs);
    if (pulseThread==null) {
      Map<Thread,StackTraceElement[]> threads=Thread.getAllStackTraces();
      for (Thread t: threads.keySet()) {
        StackTraceElement[] ste=threads.get(t);
        if (ste.length>0 &&
ste[0].toString().startsWith("org.classpath.icedtea.pulseaudio")) {
          pulseThread=t;
          break;
        }
      }
    }
    pulseThread.suspend();
  } catch (Exception e) {
    e.printStackTrace();
  }
}

...and change main to use beep2 rather than beep1:

public static void main(String[] args) {
  try {
    beep2(700,20000);
    Thread.sleep(60000);
    beep2(700,20000);
  } catch (Exception e) {
    e.printStackTrace();
  }
}

Now, no CPU isused between the beeps.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20130209/8e8cac98/attachment.html