Yesterdays problems, is todays success.
After finishing my blog yesterday, I decided to use another technique to solve my problem.
So I know the read speed was not good, I wanted to isolate the problem, or try to exclude a problem by testing, individual components.
So I wrote a small test program for libdvdcss, by doing this I hit nail on the head, this was where speed problem was.
First run it showed about 64kb/s a bit more then when I was benchmarking from mplayer.
Corrected a few mistakes and I was at 200kb/s.
The experimented with my read ahead cache implantation, and I was soon at 800kb/s.
With bit more work I managed to get it up to 24000 kb/s, this is really close to the copy speed I got yesterday from DVD to HD.
So I think we can say the speed problem is solved.
The problem with mplayer is that it tries to read one by one block, but CD has spin up, it has to find the sector where block is located, and this for every time you read one block, this not efficient.
sb600sata.device or sata device driver for X1000, does not try to pre buffer, this is the problem. So this is way I need to do that in mplayer/libdvdcss.
So what I try to do is, avoid any one block reads by pre fetchingblocks, as mplayer mostly reads blocks in sequential order this pretty easy to do, so next reads is going to be really quick, until the read offset is outside the buffer and it has to fill the pre fetchbuffer.
Also because its in memory, I do not need to foreword the IO read to the DVD read process I created, it can simply just copy the data from the buffer, so no need to wait for task switch, signals and stuff like that.
I call my pre buffering stuff "Evil" because it was quickly proto typed, as future note it should be moved into the dvdcss struct, so etch dvd device can have its own pre fetch buffer.
Anyway its not a problem for mplayer as I think there is only one process reading at any given time, from one device, I'm shore this might not be case for other operating systems.