From: R. B. <ro...@pa...> - 2003-05-10 15:00:35
|
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. |