On Tue, 8 Jul 2025 01:03:23 GMT, Alexander Matveev <almat...@openjdk.org> wrote:
>> In case of jar, the ConnectionHolder is a `MemoryConnectionHolder` (because >> Locator already has a cacheEntry) which has true for isRandomAccess. >> The cacheEntry is created by the `NativeMediaAudioClip<init>` which is >> indirectly called by the AudioClip constructor. >> >> In case `readNextBlock` is used on a MemoryConnectionHolder, it seems all >> chuncks are asked and played simultaneously (bug in >> MemoryConnectionHolder.readNextBlock?). With `readBlock` the order and >> sequence seem to be ok. >> >> Alternatively, we might try to use the already-created ConnectionHolder >> instead of creating a new one in OSXMediaPlayer.mm. > > Yes, you right `MemoryConnectionHolder` in case of jar, but only for > AudioClip. MediaPlayer does not use it. I tested AudioClip with jar with and > without random access. Without random access I only hear some clicking > sounds, so looks like it does not work completely. With random access I can > only hear audio for like 30 seconds and then it loops, so looks like it is > broken as well. > > Can you play audio file correctly via AudioClip? I figure it out. Seek is ignored for random access, so setting `pos = 0` will always read from begging of the file. We should read from `dataRequest.requestedOffset`. I am attaching proposed patch which I tested and works fine. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1839#discussion_r2191370087
