[WIP] Add read speed option

[strict-flower]

Under development

Description

Background discussion is #59

Adds an option to request to set the read speed of the tracks.

[Bloomca]

I think this API looks good! I left a few comments for the implementation, also there a few typos in the comments but we can fix it later.

I think we should an example of "slow_read_track" which would read the first track from the default drive at 10x.

@strict-flower One question I am curious about and forgot to ask in the issue. If custom multiplier does persist (we'll need to test it), do you think we should set speed back to optimal in the drive destructor?

[strict-flower]

@Bloomca Thanks for the quick review. I've fixed them. I'll write & testing the Linux implementation today.

One question I am curious about and forgot to ask in the issue. If custom multiplier does persist (we'll need to test it), do you think we should set speed back to optimal in the drive destructor?

I tested that.

The DKIOCCDSETSPEED ioctl seems to set the drive speed until the disc is ejected. Below is my experiment summary.

1. Read with Unchanged -> corrupted and 24x
2. Read with CustomMultiplier(10) -> success and 10x
3. Read with Unchanged -> success and 10x
4. Eject and re-insert the disc
5. Read with Unchanged -> corrupted and 24x

... and the default state seems to be Optimal, but we can't confirm that because DKIOCCDGETSPEED only returns the current speed¹, according to my experiments.

Footnotes

1. I also tested that. I inserted eprintln! in the read loop to print the return value of the DKIOCCDGETSPEED ioctl, and it changed between 10x and 24x depending on the actual read speed. This means that it returns the current speed. ↩

[strict-flower]

I think it's difficult to restore the original state. At least, macOS doesn't seem to provide a way to get the original state.

Moreover, we could get the read speed performance data of the drive, but we can't get the current speed policy of the drive. In other words, even if the current speed is 10x, we can't determine whether the value was set by another program, is the default value of the drive, or was selected automatically.

Therefore, I think just setting Optimal is the best way to implement the destructor. (deleted, please read the next comment)

[strict-flower]

I wrote the implementation for Linux and tested. It seems to work correctly.

Also I tested Optimal / Unchanged / CustomMultiplier with the USB-connected drive that I used for the macOS test, and it doesn't behave the same way as on macOS. I didn't retrieve the read speed, but I only observed whether the read succeeded or returned corrupted data (It could probably be obtained using GET PERFORMANCE, but I haven't implemented that yet).

1. Read with CustomMultiplier(10) -> success
2. Read with Unchanged -> success
3. Read with Optimal -> corrupted
4. Read with Unchanged -> success
5. Read with CustomMultiplier(1) -> success

Although I didn't eject the CD during the above procedure, the speed setting did not persist. On Linux, it seems to be reset on each open(2).

Additionally, I tested this on an internal disc drive (ASUS BC-12D2HT). This drive seems to ignore the requested speed with the SET CD SPEED command¹. Nevertheless, this behaviour doesn't necessarily violate MMC-3, because MMC-3 specifies that The Logical Unit is to select the Logical Unit Read Speed specified or any higher rate.

Thus, unlike my earlier comments, I think the best destructor behaviour may be OS-dependent. However, there is also the possibility that we don't need to restore the policy at all.

• macOS: Optimal (?)
• Linux: Nothing to do.
• Windows: ?

Footnotes

1. Unlike the USB-connected drive, it could read the disc correctly with all settings I tested. However, the USB-connected drive could read most discs correctly at 24x, so there may still be some hidden hardware-specific issue. ↩

[Bloomca]

Thanks for the comprehensive testing!

Alright, I believe it is easier to skip restoring and just document that the behavior is OS/drive dependent. I thought for a second to expose setDriveSpeed method on the CdReader itself but since we don't expose the the drive primitive I don't think it is necessary.

Can you please add a test where we read first track on ~10x speed, and then second track on optimal speed?

After that I think we can just merge your PR and I will make a separate Windows PR.

Note: apologies but I merged a PR which changed internal API a little bit, so there are some conflicts