[Bug 734] New: Recording from pulse-java.jar has huge latency and loses samples

[bugzilla-daemon at icedtea.classpath.org]

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

           Summary: Recording from pulse-java.jar has huge latency and loses
                    samples
           Product: IcedTea
           Version: unspecified
          Platform: all
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: PulseAudio
        AssignedTo: unassigned at icedtea.classpath.org
        ReportedBy: damjan.jov at gmail.com


My application operates by calling available() on the TargetDataLine and
sleeping until the predicted time when 60 ms of audio will be available, then
calling read() with 60ms of samples if available() reports there is enough
samples, otherwise continuing to sleep.

The following code:

AudioFormat pcm8kMonoFormat = new AudioFormat(
    AudioFormat.Encoding.PCM_SIGNED, 8000, 16, 1, 2, 8000, true);
TargetDataLine microphone = AudioSystem.getTargetDataLine(pcm8kMonoFormat);
microphone.open(pcm8kMonoFormat, 2*8*60*4);
microphone.start();
while (true) {
    int bytesAvailable = microphone.available();
    int samplesAvailable = bytesAvailable / 2;
    if (samplesAvailable >= 8*60) {
        byte[] pcmBytes = new byte[2*8*60];
        int totalBytesRead = 0;
        while (totalBytesRead < pcmBytes.length) {
             totalBytesRead += microphone.read(pcmBytes, totalBytesRead,
                    pcmBytes.length - totalBytesRead);
        }
        send(pcmBytes);
        selector.selectNow();
    } else {
        long nanosAvailable = samplesAvailable * 1000L * 1000L / 8L;
        long remainingNanos = 60 * 1000L * 1000L - nanosAvailable;
        long remainingMillis = remainingNanos / (1000*1000);
        Thread.sleep(remainingMillis);//selector.select(remainingMillis);
    }
}

gives me this extremely jittery, bursty latency between audio reads, and
doesn't provide enough samples per time period for the sampling rate (about 80%
of the samples are lost):
9.52 ms
4.23 ms
3.20 ms
3.43 ms
1999.47 ms
5.74 ms
4.42 ms
2.67 ms
1961.60 ms

By comparison, the "default [default]" mixer on OpenJDK works perfectly, giving
me 60 ms of samples every 60 ms.

Since both the "default [default]" and PulseAudio mixers go through the same
PulseAudio server, it can't be PulseAudio itself doing something wrong, it must
be pulse-java.jar. The most likely explanation is that your available() is
reporting the wrong value.


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.