[Bug 281020] Cannot play sound tracks on mixed-mode CDs (read() fails with EINVAL)
[email protected] Sun, 10 Nov 2024 18:48:35 +0000
| Newsgroups | gmane.os.freebsd.devel.scsi |
|---|---|
| Message-ID | <[email protected]/bugzilla/> |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281020 --- Comment #4 from Damjan Jovanovic <[email protected]> --- Created attachment 255077 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D255077&action= =3Dedit Implement the CDIOCREADRAW ioctl for raw CD reads After hours of trying to debug the blksize for my mixed-mode CDs, many of w= hich were wasted by the fact you deceptively cannot just replace /boot/kernel/ca= m.ko with a newly built version and reboot - CAM is statically linked into the kernel so /boot/kernel/kernel must be replaced instead :-/ - I took another approach. How do other operating systems do this? Windows: DeviceIoControl() with IOCTL_CDROM_RAW_READ and pointer to struct RAW_READ_INFO. Can read multiple sectors. Uses LBA addressing. Linux: ioctl() with CDOMREADRAW, and a pointer to a buffer with one MSF address, whose contents are overwritten with 2352 bytes from the sector with that address. macOS: ioctl() with DKIOCCDREAD, and a pointer to dk_cd_read_t. Can read multiple sectors. Uses LBA addressing. Only FreeBSD requires a change of blocksize to 2352 and then read(), which I suspect isn't viable for mixed-mode CDs (logging I added to cdstart() never even gets called when block size is 2352). So I implemented a new ioctl() for raw CD reads on FreeBSD: CDIOCREADRAW. Taking a LBA address (actually a byte offset currently, but can be changed easily), a buffer, and buffer length, the ioctl just does a blocking raw re= ad. It doesn't care about blksize, and will read (multiples of) 2352 bytes even when the blksize is 2048. And, with VLC also patched to use it, it works like a charm, all the audio tracks from my mixed-mode CDs are playing, and the data track can be mounted and used at the same time :-). Here is the patch to add that new ioctl. --=20 You are receiving this mail because: You are the assignee for the bug.=