[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.=