[haiku-development] Re: MediaPlayer in latest build

David McPaul <dlmcpaul@xxxxxxxxx> wrote:
> It's a queue of 10 pointers constantly changing, the buffers
> themselves are in rtm memory.  STL containers do allow you to pass in
> your own allocator so we could put it in the rtm pool but it hardly
> seems worth it.

The constant usage is only of secondary importance - the VM will always 
only get a usage update in quite some interval, and might need to swap 
pages that are in active use under critical low memory situations.
Needless to say, the media add-ons should be made locked in memory as 
well if "real time media" is selected in the prefs.

> I would prefer to use STL containers rather than private kernel 
> structures.

It is not at all kernel dependent (besides its location) - it should 
just be moved to shared/, lots of userland code is already using it, 
anyway.
It saves constant reallocations of the chunk array, and makes the 
management a no brainer (as in: cannot fail), as all memory is pre-
allocated.

> The performance problem is the constant memcpy from reader buffer to
> chunk buffer.  In theory it would be better if the cache could just
> take ownership of each buffer given.

Indeed, that's an API fault. I guess I will rework this as well, then.

> > Furthermore, a time based cache doesn't really make much sense 
> > either,
> > as the thing you are most interested in is avoiding disk I/O.
> Hmm, I don't see the purpose of ChunkCache as trying to buffer as 
> much
> of the stream in memory as it can.
> I think it is just there in case of a drop in I/O performance (Less
> for disk I/O but more useful for network I/O).  Once the cache is
> filled then each decoder GetNextBuffer call is matched by a Reader
> GetNextBuffer to replace the removed Chunk.  It is the same amount of
> Disk I/O just x chunks ahead

The ChunkCache is the only place where caching actually makes sense. If 
your CPU is too slow to process the media, there is no chance to have 
perfect playback, therefore you should only cache encoded data in larger 
amounts.
The only case you can (and should) try to improve is the latency 
involved with I/O. In the case of audio, it also makes sense to read 
ahead the whole file in order to let the disk rest and eventually save 
some power. Ie. it makes sense to batch several I/Os together - no 
matter if they end up as one large I/O or several smaller ones.
Of course, at least in the case of hard drives, the kernel should do 
the precaching. However, that doesn't help you in low memory 
situations, or when doing network I/O.

> I think you are seeing the ChunkCache as a mechanism to buffer up
> small chunks in memory and somehow reduce disk I/O and I don't think
> that will work.

Not to reduce disk I/O (that's what the file cache will do for us), but 
to batch it together, and make the data available when it's needed.

> The problem of the mp3 reader needs to be solved at
> the mp3 reader level.  Right now the mp3 reader reads a frame at a
> time but really should do a larger read and break it up into frames.

That would indeed be a good idea, but wouldn't solve any latency 
problems at all.

Bye,
   Axel.

Other related posts: