OSDev.org

what is closest to a real-time system on a legacy PC is MP3/video streaming. Your decoded frames have to be made ready on time so that they're not missed by the playback device.

Unfortunately, as those frames usually come from a mass storage device that has no realtime constraint (i.e. you can't determine how long the FS will need to find the next block of the encoded stream) and go through a codec which may need variable processing time (afaik, you can't predict how long a frame will need for decoding by just looking at the encoded stream, can you?) you lack informations to know how much in advance you must run the thread.

Now, you could still improve the quality of the playback by telling the disk requests scheduler "you failed to deliver 3 frames on deadlines, i want my request to become even more important" and by giving more buffer space for your 'input stream' (so that less head displacement are required) ...
You could also try to do the same for the CPU: if you see you fail to decode the frames with the given priority, make a larger playout buffer and slightly increase your thread's weight on the system.

btw, anyone who blame your OS to start a defrag or disk indexing while he's watching a DivX is just a looser that can't edit a cron job (imho)

scheduling ... ]:-> ... oh, how right you are, pype.

hm ... regarding mp3 decoding ... won't it be appropriate to split the task? one process/thread fills the sound card driver with data?it picks from a kind of circular buffer whilst another thread does the decoding and fills the buffer up - this thread is responsible for getting mp3 data from file system... the thread to be waked up regularly should be bound to a clock, hm? More important: are actual mp3 players/decoders working in such a way?

beyond infinity wrote: scheduling ... ]:-> ... oh, how right you are, pype.

hm ... regarding mp3 decoding ... won't it be appropriate to split the task? one process/thread fills the sound card driver with data?it picks from a kind of circular buffer whilst another thread does the decoding and fills the buffer up

actually, that's not necessary, as the DMA should do that circular-buffer trick (it did on SBlaster PRo, so i would be stunned if it didn't on modern cards :p )

- this thread is responsible for getting mp3 data from file system... the thread to be waked up regularly should be bound to a clock, hm? More important: are actual mp3 players/decoders working in such a way?

I don't even know if a clock-driven thread is needed: whenever you have both data to decode and buffer space to put it, do the decoding job. I guess that's how most of them work ...

Solar: I want to do it like this: I am planning to add a priority value in addition to actual priority of thread, this value will determine some scheduling policies on thread, particularly its quanta. I mean think about two normal priority thread, we do not care which should run one prior to other (so both are normal priority) but we think that one must have more cpu time so setting its quanta higher solves this, I think. This will be accomplished by different priority values. I think windows does sth like this. this value might be 1 to 100. So in addition to actual difference of priorities there will also be a soft priority difference between same priority threads.

*** content deleted by moderator ***
*** new questions should be posted in new threads ***

Are there any good books or references on writing real time operating systems. (My main OS won't be one, but I do have a couple of things in mind that one could be useful for).

srg