ADDITIONAL SYSTEM INFORMATION :
JDK 16.0.01+9
Ubuntu 18.04.6

A DESCRIPTION OF THE PROBLEM :
Thread 1

Calls
clip.setMicrosecondPosition(0);
to move clip to start
If this has the following stack trace holding the lock on the DirectAudioDevice object and waiting for the lock for attribute lock
As seen in the following stack trace
    
synchronized DirectAudioDevice.setMicrosecondPosition(long microseconds) {
    ...
    setFramePosition(frames);
    ...
}
    
DirectAudioDevice.setFramePosition(int frames) {
    ...
    flush();
    ...
}

DirectAudioDevice.flush() {
    ...
    synchronized(lock) {
       lock.notifyAll();
    }
    ...
}

Daemon Thread [Direct Clip]

At the same time is running the clip writing data out the stream and holds the lock on the lock attribute and is waiting for the lock on the DirectAudioDevice object
As seen in the following stack trace

DirectAudioDevice.run() {
    ...
    int written = write(audioData, clipBytePosition, toWriteBytes)
    ...
}

DirectAudioDevice.write(byte[] b, int off, int len) {
    ...
    synchronized(lock) {
        if (!isActive() && doIO) {
            // this is not exactly correct... would be nicer
            // if the native sub system sent a callback when IO really
            // starts
            setActive(true);
            setStarted(true);
        }
    }
    ...
}

DirectAudioDevice.setActive(boolean active) {
    synchronized (this) {
         if (this.active != active) {
                this.active = active;
                //sendEvents = true;
         }
    }
}

Is it wise / right to lock on the object and an attribute? Why do we not use a single semaphore?
If we do need two, the the order must be the same in all stack traces to avoid deadlock.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
See stack trace demonstrating how deadlock can occur in description

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
System stops with deadlock
ACTUAL -
System stops with deadlock (It is my AWT Event Thread calling setMicrosecondPosition())

FREQUENCY : occasionally