This is probably hardware-related (my CDROM is a CREATIVE CD2423E ATAPI). I think the drive spinning down causes the problem. However, since the software obviously knows that the drive has not resumed, it ought to be able to force it to do so. cdctrl is used below just as an example. cdpause/cdplay produces a similar effect.
Jonathan H N Chin <jhnc@pfaff.newton.cam.ac.uk> writes: Hi Jonathan, I've just moved my primary system over to a computer which has exactly the same Creative CDROM. I haven't yet noticed this behavior, but my drive has quirks of its own - often when I eject a disc to change it, the drive tray almost immediately disappears back into the drive. Anyway, I should be able to test your problem quite well. Does this problem happen with all cd's you try to play? Regards, Martin.
I haven't tried my complete collection, but I'd guess so.
Hello Jens, I am writing to you as maintainer of the CDROM driver for the linux kernel. I am a developer for Debian GNU/Linux, and have been following up on the following bug report regarding the cdtool suite of programs: http://www.debian.org/Bugs/db/34/34242.html As mentioned in the bug report, I happen to have the same Creative CD2423E cdrom as does the submitter of the bug. The problem in short, is that when playing audio, then pausing playback, if you leave it paused for >30 seconds, then the drive spins down, and the resume ioctl has no effect. This effect can be seen near the bottom of the cdctrl output in the bug report: CMD resume paused 2 5:24.53 0:23.71 (command is resume, drive status is paused - it should change to play) I was wondering if you have seen this before, or know of some combination of ioctls which might work around the problem?? Or is this creative drive just broken hardware? Regards, Martin.
Hi Martin, I believe this one is a drive bug. cdctrl does a "real" pause/resume command and sends it to the drive. It is the drives responsibility to resume play - regardless of whether it spindown in the time period where it is paused. The spec isn't clear on how the drive should behave, though. One way to circumvent this would be to read the current playing location immediately before pausing with the CDROMSUBCHNL ioctl. Then you can implement your own pausing - just do a CDROMPLAYMSF with the data, for instance.