Re: Bridge Testing Fiasco
Thanks for this way down in the weeds work. It would be very desirable to get the Firewire interface working with DBpoweramp.
phil
-
Re: Bridge Testing Fiasco
Just an update.For now, I'm updating the bridge testing results here:
-brendan
I have an initial set of success/fail tests on at the page listed above, of course.
Summary - I couldn't get the two different firewire chipset bridges to work with C2 at all, but had some good luck with the ALi and NEC chipset USB bridges.
Big Bonus(?):
My frustration on this led to a bit of detective work on my part over the past week and a half, which may have uncovered the source of the C2 problems over firewire. The initial evidence I collected:
- EAC has no problems with C2 over firewire with the bridges
- Nero Disc Speed has no problems either.
So, really, this doesn't seem to be a hardware issue, at least, not an external hardware issue.
I then dug deeper, with some help:
- Spoon emailed a couple of short code snippets that show how the difference on how his C2-enabled and C2-disabled read requests are handled
- I researched documentation and discussions of IOCTL_SCSI_PASS_THROUGH vs. IOCTL_SCSI_PASS_THROUGH_DIRECT from microsoft.com and in microsoft-related forums.
- I performed traces using Bushound (with some very helpful input from Paul at Perisoft)
- I performed experiments using plscsi's -X spt, -X sptd, and --align options (specifically -X sptd --align x02 vs. -X sptd --align x04)
- I BSOD'd my work machine twice (oops).
- I annoyed the stuffing out of spoon via email (well, I only guess I did, he seems fine about it...so far).
According to Spoon, cdgrab.exe uses the IOCTL_SCSI_PASS_THROUGH_DIRECT function, which, from what I have read, passes the user buffer pointer directly down the stack instead of double or bounce buffering data. This can be faster for large IO transfers.
There's some controversy about using the _DIRECT call vs. the one that doesn't have _DIRECT at the end, but I'll skip over that for now.
When the number of frames that cdgrab.exe wants exceeds a certain threshold (for some other hardware compatibility reasons?) the code breaks the read into two smaller reads, the first with a pointer to the beginning of the buffer, and more importantly, the second with a pointer to next available address in the buffer not used by the results of the first read.
I believe it is not the firewire bridge chipsets at issue or even firewire itself, but rather a sneaky pointer-alignment requirement that wasn't being met by the pointer passed down the driver stack from dbpoweramp in that second read. With regular CD-DA data, each frame of data return 2352 bytes, which happens to be easily divisible by either four or eight. With CD-DA data plus C2, we add 294 bytes for a total of 2646 bytes which is no longer easily divisible by either four or eight (just two). If the first read of the pair was for an odd number of frames, then on the second read of the pair, the pointer is only 2-byte aligned.
Other interfaces didn't care, but it appears that firewire and/or the SBP-2 layer does care and wants at least quad-aligned pointers.
This gives me hope that Spoon will be able to make some adjustments to the ripping and C2-testing engines in the near future (perhaps 4-8 weeks, if we clap really hard?) and that such changes may finally allow us to perform secure, C2-enhanced ripping over firewire with dbpoweramp.
-brendanLeave a comment:
-
Re: Bridge Testing Fiasco
For now, I'm updating the bridge testing results here:
-brendanLeave a comment:
-
Bridge Testing Fiasco
I set up eight optical drives in a specialty hot-swap tower for testing bridge board + drive combinations for what features worked and which combinations were stable.
Well, the tower was shipped configured for 240V instead of 120V.
So, half of my bridge boards just died. Sadly, I'd put in the ones that were most likely to work, so now I've got a pile of dead bridge boards and known incompatible bridge boards.
Sniffle.
-brendan
Leave a comment: