All about ASPI and SPTI

Topic: All about ASPI and SPTI (Read 22695 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

All about ASPI and SPTI

2004-03-05 20:24:41

Let me begin by saying that I'm no expert on this subject matter. All information presented here has been collected off the internet from what I believe to be reliable sources. This is a rather lengthy post; sorry. And I didn't find anything like already posted. I spared no breath, or keys, to ensure that this is as complete as I can get it. I appreciate any and all feedback.

In trying to ensure that I had the perfect setup for ripping and encoding audio files, I became confused on the differences between ASPI (Advanced SCSI Programming Interface) and SPTI (SCSI Pass Through Interface). Many guides on using and setting up ExactAudioCopy stated bluntly to download and use an ASPI driver if you were using a Windows NT based system (NT/2000/XP). These guides failed, however, to say why I should. Using Windows 2000 at work and Windows XP at home, and having ripped many CDs without error, I wanted to know what was wrong with using SPTI. Not wanting to take some Joe Shmoe's word for it, I decided to investigate myself. Most of the answers to my questions were scattered across the internet, so I thought it proper to write my findings here. Hopefully this will help others who are confused.

ASPI was developed by Adaptec in the early 1990's. The purpose was to create a standard "layer", or set of device drivers, which applications could use to communicate with SCSI (Small Computer System Interface) bus based drives. This layer works at a very low level, to "talk" with the hardware directly. Thanks to some standardization in the way we access drives, the capabilities of the ASPI layer has been broadened to include other bus technologies, like IDE (Integrated Drive Electronics), ATAPI (AT Attachment Packet Interface) i.e. CD Burners, and SCSI-like i.e. parallel port. Missing a similar technology in their Operating System, Microsoft licensed the layer for use in their Windows OS, beginning with Windows 95.

With the birth of the CD-ROM burning market around 1995-96, Adaptec decided to change their licensing conditions. Namely, Adaptec asked for the kind of software and even for the name of the programs which would be distributed with the ASPI layer. Microsoft always had mixed feelings about the ASPI layer due its lack of security. With Adaptec's license change, they decided to write their own layer called SPTI, and do away with the ASPI layer. SPTI serves the same purpose as ASPI, in that it is used to communicate with the hardware at a low level. SPTI is also referred to as native Win32 or Windows NT/2000 calls, method, or interface in applications when setting up how the program will "talk" to the drive. Microsoft began including this in their NT based OS's (NT4, 2000, XP).

At some point a fight broke out between Adaptec and Microsoft over the licensing of ASPI, and Adaptec began to offer updates only to owners of Adaptec products. Advancements in the computer bus technologies left users of Windows 9x and ME with a very outdated ASPI layer.

Adaptec has since changed their policy, probably fearing they would lose their industry position, and currently offers their latest ASPI layer, version 4.7x, for almost all versions of Windows (98, Me, NT4, 2000 and XP). Windows 95 users are instructed to use the 4.60 version. To complicate matters, other companies, like Ahead Software, makers of the Nero Burning ROM application, offer their own ASPI layers.

So for SPTI enabled version of Windows (NT4, 2000, XP), you probably have the option of using either SPTI or ASPI (assuming you've installed an ASPI layer). Near as I can tell, the issue of which one to use, usually boils down to which layer the application supports. For instance EAC supports both, while Nero Burning ROM uses their own ASPI driver. I have yet to find documentation as to which layer offers an advantage over the other one. One site did state that little work was done on creating SPTI because the author of Adaptec's ASPI layer, Dan Polfer, did such a good job. I'll let you make your on conclusions on that statement.

I have seen many arguments surrounding the different versions of Adaptec's ASPI layer, including use of the 4.60 version in Windows NT based system and whether to keep updating the ASPI layer as new versions are introduced.

Adaptec's website states that the 4.60 version is not supported Windows ME, 2000 or XP. However, many users on the net have posted that they have experienced less problems using 4.60 versus 4.7x versions when installed in those OS's. The general consensus is that Adaptec's 4.60 build 1021 version is the most stable version available. The newer 4.7x versions seemed to have issues regarding reliability and stability.

Alternately you can use ASPI layers from other vendors, like Ahead's, which can be used independently of their recording software. RecDev is another example, whose ASPI layer supports external drives, such as USB and FireWire, but only works on Windows NT based system.

To re-iterate the Microsoft security concern with the ASPI layer, as a service under Windows NT, the layer allows all users direct access to the hardware without any rights attribution by an administrator. This is why, on NT based systems, after an ASPI layer is installed, ASPI access is limited to users with administrator rights. Of course, Microsoft recommends using SPTI.

Through my searches it has seems to me that if your application supports SPTI and works like you expect it to when using SPTI, continue to use it. If it only supports ASPI or using SPTI seems flaky, install Adaptec's 4.60 build 1021 version or a layer from one of the other vendors. Whether you use SPTI or ASPI, once you have a working configuration, it's NOT recommended to change. There haven't been any updates to the underlying technology, so unless you're experiencing a problem you risk breaking your configuration. And if you break your configuration, it can be hell trying to get it back in working order.

One last note is that Microsoft also created another drive access layer, called IOCTL (Input/Output Control). From what I can tell is that this doesn't access the hardware at the same level as the SPTI or ASPI layers. Instead this adds another layer, with the purpose of making the ASPI and/or SPTI layer even more generic and general. I don't believe DAE is possible with this layer, hence you don't hear much about when talking about ripping CDs.

Like I said earlier, I hope this helps others out there that were confused about the differences. If you believe I have incorrect information, please let me know so I can correct it.

All about ASPI and SPTI

Reply #1 – 2004-03-06 01:13:17

Probably the best first post on this board ever.

This stuff should be in the HA wiki.

All about ASPI and SPTI

Reply #2 – 2004-03-06 02:21:30

Great research! Thanks a lot.

All about ASPI and SPTI

Reply #3 – 2004-03-06 03:32:05

Thanks for the indepth research. Welcome aboard.

All about ASPI and SPTI

Reply #4 – 2004-03-06 04:18:25

Thanks for the compliments! I didn't want to lose all this good information I was finding on the different layers, so I figured I'd share it with everyone. I also thought the wiki would be a good place for this, but I didn't want to add it there without getting some inital feedback. I'll have to add it there tomorrow; too tired now..

One addition to make though. I did notice that in the Toaster Factory's EAC tutorial (which is embeded in HA's EAC wiki) it noted that the SPTI is buggy. After checking on the EAC forums, it seems the SPTI support in EAC isn't 100% perfect, but it looks like it is getting there. I had read one post on some developer's forum which stated that both ASPI and SPTI aren't easy to work with. Both can be a little tricky and don't have very good documentation.

All about ASPI and SPTI

Reply #5 – 2004-03-06 05:11:51

Niiice first post indeed. And much appreciated, cman. I'd always wondered about this; never bothered to take the time to look up the answers myself though--just took the hype about aspi 4.60 being better for truth...

Would love to hear more details if anyone has some to offer.

All about ASPI and SPTI

Reply #6 – 2004-03-06 07:53:33

Quote

Probably the best first post on this board ever.

This stuff should be in the HA wiki.

I must agree, this probably is the best 1st post, of any forum I can recall.
I believe this would be a valuable entry in the Wiki as well.

I bow to you, Sir. Excellent work.

I didn't notice anything in particular which was incorrect, fwiw.
Perhaps you can post at CDFreaks Optical Storage Technical Discussions forum, if you're interested.

Maybe Pio2001 the Great (or JeanLuc?) will see something that is incorrect.

Again, nice job, tec

All about ASPI and SPTI

Reply #7 – 2004-03-06 08:45:15

Double thumbs up from me ... since I only have two thumbs to raise ... ;-)

You could, additionally, post this on the EAC board at http://www.digital-inn.de ... there is a sticky ASPI-related thread over there.

You could possibly add that SPTI is being referred to as Device I/O Control by another famous application ... Feurio! ... but that would just be some cosmetic change.

Keep up the good posting ...

All about ASPI and SPTI

Reply #8 – 2004-03-06 09:07:51

This looks like excellent material for the wiki. I just changed to Nero's latest ASPI since the adaptec one was giving me some crashes in EAC.

All about ASPI and SPTI

Reply #9 – 2004-03-06 09:53:00

I never had trouble with ASPI under Win98 or ASPI/SPTI under WinXP. Using SPTI, installing ForceASPI (Adaptec 4.60) or to put Aheads WNASPI32.DLL manually in the program folders, it always worked with every application and drive.

What are the problems people have with ASPI/SPTI?

I know of drives, that aren't detected, that are detected, but show no audio-tracks or that rip tracks with silence.

In these cases, you can be sure there is something wrong with ASPI/SPTI. But I wonder, if there are hidden problems (slower DAE or something like that)?
Or to put it in a short question: When do I have an ASPI-problem?

The answer to this question might be helpful in a Wiki, too

All about ASPI and SPTI

Reply #10 – 2004-03-06 10:50:00

Quote

I have yet to find documentation as to which layer offers an advantage over the other one

One advantage of SPTI is that it cannot 'arse' like ASPI can (if different versions are on the computer). Plus ASPI will go it's self use SPTI, think of it as not needed, and finally it is very difficult for programs to match a drive letter to an ASPI device, normally programs will detect the 2nd ASPI device and work down through all the drive letters c..z looking for the 2nd CD rom, which will not work if the letters are swapped / assigned differently. SPTI has no such problem (the drive is opened raw).

BTW both ASPI and SPTI will require admin rights to access, only the built in IOCTRL CD Rom commands do not (I don't know of any better way of naming them).

All about ASPI and SPTI

Reply #11 – 2004-03-06 12:41:44

I have to agree, great post, and thanks for the information

All about ASPI and SPTI

Reply #12 – 2004-03-08 21:51:31

Well I got some more goodies to share. I just need a little help digesting it..

I found an MS Knowledge Base article [MS KB 251369 ] that details some limitations of SPTI. One is that it only allows synchronous requests to the layer. The ASPI32 Technical Reference [here] states that ASPI is fully re-entrant and permits overlapped, asynchronous I/O. Again, I'm not a programming/hardware guru, but it sounds like ASPI would be faster as it can handle multiple I/O requests at the same time. But then again, wouldn't this be utilizing the drive's buffer to accomplish this? Which, from a EAC configuration standpoint, is bad. Right?

In the same KB article, it also states that SPTI only accepts untagged queuing commands. Basically, tagged commands allow the drive to accept a series of commands from different sources, while untagged accepts commands from only one source. Once that command has finished executing, it can then accept commands from other sources. Now I don't know which layer has the advantage here, but I do know this goes against one of the performance gains to using SCSI devices. However, I think those gains are really only realized in a RAID setup with multiple drives.

Well, at least I feel a little more comfortable in that there doesn't seem to be any huge gains/loses to using either layer. And like I said, let me know if you spot any errors. I'm shooting to add this to the wiki tomorrow. I've never added to a wiki before, so this ought to be fun!

elmar3rd:
Still trying to find out if there are any "hidden" problems with SPTI/ASPI. And hopefully I'll be able to answer the question of when is there a layer problem. I'm guessing though that do to all the different system configurations and software combinations, this is one is more of an individual answer. And as always, if it ain't broken, don't fix it.

spoon:
Thanks for the info. It does seem that SPTI would be easier to implement, in that it works more "seamlessly" with NT-based system than ASPI does. Still trying to dig up information on security though. I thought that, at least with SPTI, you could enable user/group rights through the Global Policy Editor (gpedit.msc) or something similar. Since ASPI isn't a native component, there is no way to grant access to other users/groups. Now, I don't think this would stop anyone from placing the WNASPI32.DLL in a programs root directory, and thereby gain access to ASPI functionality. Don't know though.

All about ASPI and SPTI

Reply #13 – 2007-02-12 18:09:54

CMAN: Thanks for this research!

I've been programming ASPI when making a tape reading application (yes, there are actually someone, don't know who, that finds 2GB worth storing on tape rather than disk) And to make it even better, they are stored in variable block sizes using UNIX and I'm reading them into a WinXP environmet using my C#.Net app with ASPI 4.60 (hav tried others, but find this most reliable).

The reason why I write this: When I've desperatly searched for info about this, I've entered this forum quite some times. So I'd like to add some few tape tips for those other few souls working with tape drives. I'll now try to mention my most hard learned lessons when trying to implement ASPI and SPTI in my application.

First: Not all SCSI Host Board Adapters (HBA) have drivers that allow for more than 64KB blocks to be transfered. With ASPI when setting the device block size using a SCSI Mode Select cdb (command descriptor block), you will get a SS_ERR, while the target status is STATUS_GOOD and the hba status is HASTAT_OK. So, not much info to go on there. With the SPTI I've got nowere when trying to get it to accept block sizes over 64KB, but ASPI allows for alot more. Back to the HBA: You need to set the number of Scatter/Gather elements to sufficient size. This is done in the registry by using regedit.exe, and tips on how to do this is found on the internet. If you are interessted in transfering 256KB blocks, set the MaximumSGList to 65. This will give you 65 x 4KB = 260KB maximum block size. Read SCSIcard manual to find max value, sometimes max is 255 (1020KB).

Second: Reading smal variable block sizes (512 bytes and under) will cost you some time sice the data returned per command is small. To get a extra boost, you should try to treat allready read data while you wait for completion of the Read command.

Third: Adaptec ASPI has a good match between the SCSI address you get from kernel32's GetFile through the SPTI's IOCTL_SCSI_GET_ADDERSS. So you may have a link between the windows symbolic name like \\.\Tape0 and a ASPI device. But this is not equal for all ASPI packages. So my advice is to fully stick to ASPI. Use standard SCSI commands to find ProductID and VendorID through the INQUIRY cdb instead of using things like WMI (Windows Management Interface).

Last: When working with WindowsXP, ASPI and SCSI cards. Reboot as soon as you've done something with the drivers (and regedit). Windows don't ask you to restart, but you should! Or else: BSOD (The blue screen of death) like STOP 0x0000008E aspi32.sys (assuming you have chosen the BSOD option instead of sudden reboot )

Hope someone finds this usefull some time

-Amund

All about ASPI and SPTI

Reply #14 – 2007-02-14 10:48:52

I have just quickly skimmed down this thread and would just like to add that :

a) Nero's Win NT/2k/XP wnaspi32.dll file is not a real ASPI layer but an ASPI wrapper for the SPTI interface, which means that it simulates ASPI and accordingly translates the ASPI commands back to SPTI.

b) With EAC, then when using USB/FireWire drives, then most times Nero's wnaspi32.dll file is needed instead of Andre's SPTI implementation to make the drive show up propperly in EAC.

c) In the beginning where Andre implemented SPTI support in EAC, then it was a little buggy and hence, this is why there are still many of those old warnings floating around the web and e.g. also still used in many guides, but the SPTI implementation has been overhauled by Andre a long time ago, and so now it should be pretty good implemented. Andre himselve says that if SPTI works for you, then there's absolutely no reason not to use it, and when i say "works for you", then i simply mean that you aren't getting a BSoD It's really as simple as that

CU, Martin.

Notice