Windows alignment (raw isrcs)

[JonnyJD]

This branch hopefully fixes issues with some drives on Windows.

The first step is to get the alignment from the adapter and the next to use that alignment when issuing scsi commands like mentioned in http://msdn.microsoft.com/en-us/library/windows/hardware/ff560521%28v=vs.85%29.aspx.

[JonnyJD]

@phw:
This could possibly fix the issue with your drive where no scsi command worked at all.

Unfortunately I only know this compiles. I couldn't test this with any drive since I don't have a windows machine available again.
I made binary at libdiscid-w32-align.zip.

[phw]

Did just a quick test. Both my infamous problem device and the external drive, for which the raw SCSI code works, fail in get_device_info with "couldn't get device properties".

[JonnyJD]

I made some fixes.
Stalker-X got alignment: 1 on the failing drive now, but it doesn't help.

So gathering the alignment seems to work, but either aligning doesn't help or I am not doing it correctly.

EDIT:
alignment = 0 means no alignment and it can be 1, 3 or 7.

[phw]

That helped for getting the alignment. Result on the problem device:

libdiscid 0.6.1
Device used: e:
alignment mask: 1
data requested, but none returned
Warning: could not fetch features
Warning: raw ISRCs not available, using ISRCs given by subchannel read
WARNING: can't read subchannel data!
MCN        : 0602537286041
Track 1    : USVR91379301
Track 2    : USVR91379302
Track 3    : USVR91379303
Track 4    : USVR91379309
Track 5    : USVR91379304
Track 6    : USVR91379313
Track 7    : USVR91379305
Track 8    : USVR91379306
Track 9    : USVR91379312
Track 10   : USVR91379307
Track 11   : USVR91379310
Track 12   : USVR91379308
All features: read, mcn, isrc

Same result as Stalker-X got I suppose. The external drive also returns the alignment now (0 in that case), rest still works as expected.

[JonnyJD]

Well, having alignment on the failing drives and no alignment on the working drives (we only tested on of the working drives though) is an indicator that this might go into the right direction.

Possibly we need to do something with the buffer length, too.
I found this:

DataTransferLength

Indicates the size in bytes of the data buffer. Many devices transfer chunks of data of predefined length. The >value in DataTransferLength must be an integral multiple of this predefined, minimum length that is specified by >the device. If an underrun occurs, the miniport driver must update this member to the number of bytes actually >transferred.

I didn't find out how to get the preferred chunk length. This is possibly the same as the alignment.
However, since the alignment is 1, any multiple of 2 should be fine and FEATURE_BYTES = 4000 is a multiple of 2 anyways.

[JonnyJD]

Trying a multiple of 512 for data length. Just because this is an often used power of 2..
Not sure if that makes sense, since we are not talking about hard disks here.

[cyberluke]

Download not working: http://mbsandbox.org/~jonnyjd/dev/libdiscid-w32-align.zip

I want to test on old Nakamichi drive in Windows 98 and on Teac on Windows XP.