[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> 
> 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 

Best regards,

Other related posts: