[xine-devel] CDDA plugin caching

[R. B. <ro...@pa...>]

I noticed caching was added recently to the CD-DA plugin. Some
questions and concerns. First, has anyone noticed performance problems
without the caching? Are there any statistics to show how much better
things are in this particular case? 

My own experience seems to suggest that caching is not needed. It just
may be my own fast hardware, but here is what I've noticed. In the
experimental CD-DA plugin (and the experimental Video plugin) where
keyboard entry allows you to switch between tracks, there is a
distinct lag between the time of keyboard entry and the time things
take effect. What is going on is that a number of audio frames have
*already* been queued up on the xine-engine so there is a several
second delay before these get played. In other words, I think there
already is a cache in the audio queue. At least for a fast CD-ROM or
if you are reading from a CD disk image as the experimental plugin
allows you to do.

However if caching is needed here as well as inside the audio/video
caches rather than add caching code to the various input plugins
wouldn't it be better have caching in one central place?

Also, I don't see checks for reducing the number of blocks that get
added to the cache if you would be reading past the end of the
track. If more sophisticated event handling were added, there'd
probably need to be code to flush the buffer some sort of
discontinuity.

Lastly, I note that building the cache is done by reading a block at a
time. In the CD reading library I'm working on, there are provisions
for issuing a command to the CD controller to read multiple blocks in
one shot. At least that's true for mode2 format2 blocks.  If the
device is a SCSI device (or packet driver) the capability is in the
library although I haven't (yet) exposed that at the API level for
audio reading. However I'll put that on the list of things to do.