[haiku-development] Re: Scheduler algorithm improvements
- From: Stephan Assmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 16 Nov 2009 17:38:51 +0100
On 2009-11-16 at 11:40:36 [+0100], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
wrote:
> Stephan Assmus <superstippi@xxxxxx> wrote:
> > These threads you mention above should indeed get a higher priority.
> > Event queue runner and playback manager are timing threads.
>
> So what priority should they have? Are they computational intensive, or
> should they get really high priorities for exact timing?
From what I recall, these are management threads. The EventQueue is only
used for timing related purposes in MediaPlayer, but it is a generic class
that runs code at a certain time, and that code may in theory be
computationally expensive (not in MediaPlayer though). The PlaybackManager
is a BLooper that I think is only used for synchronization and starting
nodes and stuff like that. From memory, I think it does nothing
computationally expensive either.
> > The
> > Extractor thread should, IMHO, not really be so important, but what I
> > noticed is that many media readers work with *very* small read-
> > buffers. You
> > can see this with the MP3 reader for example, if you playback an MP3,
> > you
> > can see te harddrive LED flash all the time, because it reads so tiny
> > chunks. I don't really see the philosophy behind this, maybe Marcus can
> > explain.
> > The "ChunkReader" is supposed to read chunks from media files ahead. It
> > does a read-ahead of four chunks in advance, if memory serves.
>
> Why not simply let ChunkReader take the chunk size into account, and
> buffer much more in general?
I am undecided whether it's better to read ahead according to memory
available, or by buffering a certain time span into the future, regardless
of how much memory that would take. IIRC, the ChunkReader may be able to
tell the supposed chunk start times (PST).
> > Additionally, MediaPlayer does it's own read-ahead buffering for audio,
> > always up to the next seekable audio keyframe/chunk.
>
> And that is refilled when you reach the keyframe? (so you are at least
> one key frame ahead?)
Yes, in theory. Ingo wrote this code originally for eXposer, so it's been a
while. But as far as I can tell, it works like it is supposed to. I've seen
some weird seeking behavior with the FFmpeg reader, because I may not have
implemented seeking correctly there. If one for example enables MP3 demuxer
support in the FFmpeg plugin, things don't appear to work quite as
designed. The problems become less apparent when the ChunkReader is
disabled. But in theory, the two layers of read-ahead buffering should not
get into each others way. I have not yet investigated this very
throughroughly.
Best regards,
-Stephan
Other related posts:
