Looks good. Happy to see the tests too. Dan
> On Mar 22, 2016, at 2:22 PM, Alex Menkov <[email protected]> wrote: > > 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 >> >>
