PATCH: to implement toc and position shadowing in cdrom
eric.pouech at wanadoo.fr
Sun Feb 16 02:08:40 CST 2003
Waldeck Schutzer wrote:
> Hi Eric,
> Sorry to keep you on hold for so long. Here is my proposal for toc and
> position shadowing that should address those performance and functional
> issues we have already discussed and are summarized below. I've tested
> it with cdplayer and it seems to be working pretty well now. To my
> surprise and complete dismay it even worked the first time! It's ugly, I
> know, but it should do it. I don't dare to delve into the BSD parts.
> I'll leave these to a BSD expert.
> Issues addressed by this patch
> 1. cdrom.c
> 1.1 Some systems/drives are very slow to read the TOC. To address this
> issue, we are shadowing it inside the driver.
> 1.2 Windows will seek while not playing, Linux will not. We are
> providing better compatibility with Windows by also shadowing the
> current position.
> 2. mcicda.c
> Windows will play data tracks as audio silently, Linux won't play at
> all. With this patch we are simply avoiding playing data tracks. This is
> important, otherwise CDs beginning with a data track will not start
> playing unless you seek to the next audio track first. Since seeking to
> the next track while stopped was impossible before the above patch to
> cdrom.c, these disks would not play.
* in SyncCache (and some other functions), I don't understand why you
test dev against the [0,26[ range. Either, dev is the driver letter
(A..Z) to which the cdrom is attached, and in that case I don't see how
you could use this value as a valid fd in ioctl. Or, it's the fd opened
on the cdrom, and there's no reason it would be in the [0,26[ range.
Yes, the code is misleading. The dev in CDROM_Open means the drive
letter, and most of the other functions take a fd in their dev function.
* for memory allocation, better use the HeapAlloc/HeapFree instead of
the malloc/free. We'll be better off in the long run (especially in
* I wouldn't use in the cdrom_cache structure the Linux structures. As
it is, it won't compile on non Linux platforms. I'd rather use the
Windows one (so that it'll ease porting to other OSes). Moreover, this
would allow a better coding in cdrom.c. We could split the low-level OS
dependent functions on one hand (reading toc, position...) from the
highest level (including caching, seeking...). (Unless we only need
caching, and seeking functionalities in Linux, which I'm not sure of).
* you could perhaps factorize the code that computes the correct frame
address (when skipping non audio tracks).
* btw, did you test what windows was returning in this case as the set
of tracks on the disk. In wonder whether all the tracks (including the
non audio) are returned thru the mcicda interface (or perhaps the
leading non-audio are not reported).
More information about the wine-patches