Archived

This topic is now archived and is closed to further replies.

well this has me stumpted (ogg + multithreading + debug = slow)

This topic is 5043 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

ok. here is the situation I''m using the ogg vorbis static libs to decode ogg files, streamed, on a seperate high priority thread, to small, 8kb sound buffers. Raw directsound buffer managment foolery. Ok. the symptom: when running a debug build, (it''s no where near as noticable in release) the ogg read function (ov_read) will take around 6 seconds to run (only every so often, on certain files - usually once in every couple of files). (thats decoding around half to 1kb of data). However, if I run the thread at normal priority, it runs perfectly (it''s just I need it high priority so the sound doesn''t skip when the main thread is really pummling the cpu) The thread is locked whenever anything is happening between it and the main thread so I don''t think it''s a sync problem. If I change the threads priority to normal just before ov_read and then back to high just after, the delay is no where near as noticable (say, 1/4 a second). I really have no clue why this is happening. for me high priority is 1 btw in SetThreadPriority | - My project website - | - email me - |

Share this post


Link to post
Share on other sites
yeah I don't know if I made it obvious, but it only happens once in every probably 1000 calls to ov_read, but it's still really, really annoying when it does... Getting a 6 second stall (and it always seems to be exactly 5.7 somthing seconds) just out of nowhere...

In every 10 minutes of running time it may happen 2 or 3 times.

once again works perfectly with a normal priority thread when calling ov_read (i've put a timer on the call and a break if it's over 1/100th a second and it never occurs with normal priority)...

[edited by - RipTorn on February 22, 2004 5:27:36 AM]

Share this post


Link to post
Share on other sites
Quote from this site.

"Use HIGH_PRIORITY_CLASS with care. If a thread runs at the highest priority level for extended periods, other threads in the system will not get processor time. If several threads are set at high priority at the same time, the threads lose their effectiveness. The high-priority class should be reserved for threads that must respond to time-critical events. If your application performs one task that requires the high-priority class while the rest of its tasks are normal priority, use SetPriorityClass to raise the priority class of the application temporarily; then reduce it after the time-critical task has been completed. Another strategy is to create a high-priority process that has all of its threads blocked most of the time, awakening threads only when critical tasks are needed. The important point is that a high-priority thread should execute for a brief time, and only when it has time-critical work to perform."

As for the reason, I'm guessing because it's in debug mode. Think about it. In debug mode, you have the ablity to stop any and all threads and processes to see what's going on, step through the code one line at a time or even one instruction at a time. That's a lot of INT 3's which need to be processed or ignored. Add on top of that a high priority thread which needs to be interrupted, and it seems like it would only naturally cause minor deadlocks. I would say stick with making the thread normal or, at worst, changing the thread's priority as above (both in your post and in the article). But maybe you can find a better, more accurate solution in the article. Good luck!

[edited by - Nychold on February 24, 2004 11:06:23 AM]

Share this post


Link to post
Share on other sites
Thank you for your reply.

I sleep the thread 20ms ever iteration... since the minimum length of my sound buffers is around 100ms.. so this hopfully guarentees it''s going to keep the buffers updated and not use too much CPU (I found its faster this way than using the main thread updating every frame).

The thing is the actual ov_read function occasionally taking rediculous amounts of time, even though it''s streaming the audio and only dealing with around half a kb of data. Taking 6 seconds is quite rediculous. And, being a high priority thread, it locks up pretty much everything else with it too. It''s just odd since at normal priority it runs perfectly (ie, the ov_read functions never take any noticable amount of time to complete) I put in a 1/100th second measure that would break, and it never occurs. I have managed to ''step through'' when it''s taken 6 seconds, and the code jumps into around 3 other ogg functions as far as I can tell.. No recursion or anything like that..

it just has me stumpted because it really doesn''t make sense to me.

Ahh well it seems to work fine in release so I guess I can live with it.

Share this post


Link to post
Share on other sites
Hmmn...

(some?) disk reads, IIRC, will operate at the higest priority (which is why reading up the floppy drive will sometimes lock up the computer).

Perhaps when you''re running the reading thread at higest priority, your preventing the disk reads becoming the active thread, therefore, you''re not getting the data.

I suggest you drop down to a lower priority (possibly even normal). Running anything at the higest priority is generaly "A Bad Idea" unless you''re doing things like writing drivers and such.

If you''re getting skips with the main thread hammering the execution time, just make sure it is capable of giving up control every now and then. Perhaps let it know how much buffer you''ve got left, and release control if you need more? Making either thread a higher priority than normal is really not the solution.

As Nychold said before, debug mode with make things worse, because you have to have to have debug code running too, which can really mess with thread priorities and such.

Share this post


Link to post
Share on other sites
I''ve timed the disk reads that ov_read uses, and they are all fine (I''m using the function pointer version of the vorbis functions not the ones that use fread, etc), so it''s not disk reading...

the problem is when the main rendering thread gets down to, say, 5fps, then things go wrong if the sound is also tied into the main thread aswell, and if the sound thread is normal priority, because I''m sleeping it to keep it''s cpu usage down, when the main thread is rendering this slow it takes a fair while for the sound thread to get back to work.. unless it''s slightly higher priority.

quote:

I suggest you drop down to a lower priority (possibly even normal)



The priority of the thread is 1 higher than normal, so it''s not realtime or anything like that, and I can''t drop it any further.

As I said I''m happy to just work around the issue (I have it setup so only release builds run at the higher priority since they run fine - debug normal but it means the sound skips every so often).

Yeah the thread is only ever active probably 1/1000th the time, since it is sleeped for the vast majority of the time.

It just seems a bit, well, weird.

I''m thinking it''s just an issue with debug builds, since I guess I''ve experienced similar problems with camera monitoring threads in the past when I''ve made them higher priority...

Anyway. Thanks for all your replys. Since I wrote the original message I''ve pretty much decided just to put up with the problem.

Share this post


Link to post
Share on other sites