Looks good to me. --alex
On 21.03.2016 19:54, Sergey Bylokhov wrote:
Hello, Audio Guru. Please review the fix for jdk9. In the fix I remove the check on maximum possible size of the file(now the maximum size will be 0xffffffffL which is maximum value for the unsigned int - and maximum size of WAVE according to the spec), Right now I cannot reproduce the hang which described in JDK-7058700(using the same technique), possibly was fixed by the different fixes. Note that we have two methods to get the size of the audio data(in frames) - via AudioFileFormat and via AudioInputStream. It is interesting that AIS uses the long type for the size, but AFF uses int, this causes lost of precision in some cases. I guess this is why the AudioFileFormat for the wav format always set length in frames to "-1"(which is unknown), but set correct value for the AIS. In the fix I update the case when the size is less MAX_INT, because such values can be stored in AudioFileFormat also. In the tests I manually create two WAVE headers(wave_float and wave_ext), and verify that the data read from the sound API is correct: - long AudioInputStream.getFrameLength() always returns correct length(0 - 0xffffffffL) - int AudioFileFormat.getFrameLength() returns correct data if the length is less than max_int(0 - max_int) - int AudioInputStream.available() always positive, even if the data inside is bigger than max_int. In a future task I will investigate how we will work, if we get an overflow when other properties of audio file is huge(channel for ex.) Bug: https://bugs.openjdk.java.net/browse/JDK-8132782 Webrev can be found at: http://cr.openjdk.java.net/~serb/8132782/webrev.00
