Cool VL Viewer forum

Not really, because llassert() is only actually executed for DEBUG builds...

But yes, that llassert() shall be removed... or replaced with llassert_always() and the mOffset < 0 stuff removed.

I think i found the sound issue.

The problem is the fetching of the completions, it seems that for sounds it never fires.

If i move the Completion part into a LLLFSThread::runCondition() method instead of the processNextRequest() it fires and sounds start to play again.

Might be related how the audio part handles its completions.

Just a quick update with some more (superficial) testing I made: sound does not seem to be the only affected type of assets. I also get a lot of animation duplicate requests warnings in the log...

For sounds it is the following mix of problems (for Windows currently, but probably Linux is the same).

1) mBytesRead is reset to 0 in ReadFile/WriteFile before handing off the OVERLAPPED Calls
2) The llaudiodecodemgr uses mBytesRead as a marker for completion, as it sets it to -1 first and then sets it to the correct value in completed().
3) So when the async I/IO starts, the file handle is in use, but then the audio part checks for size=0, logs an error and tries to fix it by deleting the file (which fails).

That spams the log file and can be fixed by using NULL for the result param, so it does not get zeroed.
DWORD status = ReadFile(mFile, mBuffer, mBytes, NULL, &mOverlapped);

The second (and main) issue seems to be that the GetQueuedCompletionStatus(mIOCPPort, &bytesProcessed, &key, &result, 0); or equivalent io_uring_peek_cqe() call isn't reached, as the LFS thread goes to sleep. If i move the completions to the runCondition() method instead, the completions get processed just fine.

I did a few changes on the Windows side of the patch.

This restores sound for me and i noticed no strange log messages anymore with it present. Changes are mostly the same as describe, i moved the Completion into the "threadedUpdate" method of the QueuedThread, not sure if thats a good place or if it should be moved to somewhere else alltogether.
With some more fixes, it works with proper sound on Linux as well, at least for my quick tests.

I didn't see the other messages you mentioned about animations or other assets, hopefully those are also now working.

A couple of things seem off to me in this new patch:

• There's obviously a missing "sRingInitialized = true;" for Windows, just after the "mIOCPPort = CreateIoCompletionPort(...);" line.
• You changed mBytesRead(0) to mBytesRead(-1) in the request constructor but this might break the non-io_uring code (used when sUseIoUring is false). I suggest instead using mBytesRead(sUseIoUring ? -1 : 0)

Also, the LLLFSThread::processNextRequest() method can be removed entirely and the matching processNextRequest() method in LLQueueThread can be made non-virtual again.

Well, I have been using this slightly modified patch (with the few changes described above), but it still fails to play (non-cached) sounds for me under Linux (not yet tested under Windows here):

I looked at your updated patch.

The issue with sound comes from setting mBytesRead = 0 too early (while the async read/write is still in flight).

So adding the "mBytesRead = mBytes; // Success" back, breaks sound again.

The problem/reason for this is in llaudio/llaudiodecodemgr.cpp around line 495:


As you can see, it uses the -1 as a marker for "not yet done" and 0 or more as marker for "done". So if the lllfsthread codes sets the mBytesRead to anything but -1 before the actual async read/write is completed (for a sound), this breaks down and the error handler for sounds kicks in and loading of sounds fails.

That should work for my patch and i see .dsf files created in the cache area properly. I wonder why it doesn't work for you.

Do the completions get collected ( does io_uring_peek_cqe return 0 and populate a cqe? Your patch does "have_work = io_uring_peek_cqe()" which has the logic reversed ).
I had some issues when the LFS thread was set as idle and slept and completions would not get collected in my first tries.

Edit: Missed the (non-cached) part. Will have to check it works properly with a cleaned cache.

I grabbed Henri's patch and applied it. A quick build and test has sounds playing for me in Linux. Is there anything I can do to help test or narrow down? The only 'custom' I have in my builds is using the new curl.

I removed that from my latest patch... Might have uploaded an intermediate "v6" patch... Still no joy with that line removed anyway.

It does not work for me...

Again, this was since fixed...
I can only play *cached* (in the asset cache) sounds here...