MMC Command Read Buffer Capacity

OSR_Community_User · August 19, 2007, 7:55pm

Hi,

I am debugging a problem we have with our own legacy CD Writing software
which fails on certain CD Writers such as the NEC 3540A. The problems
appears to be related to our use of the MMC command Read Buffer Capacity (We
use TAO writing and the required features are current). Our software assumes
that if the “Available Length of Buffer” field returned by the Read Buffer
Capacity command is non-zero we can continue to write and when it is zero we
should pause.

Problem is that when using this unit it does not work. It always returns
Zero bytes available even when we wait 10-20 seconds. Also, I used an
analyzer to see what a popular commercial CD Writer package does. This
package just keeps writing even when the Read Buffer Capacity returns 0
bytes free.

Can anyone help me with this and explain how the information returned by
Read Buffer Capacity is supposed to be used ? (I am using this to avoid
overflowing the CD writers buffer cache or this the wrong approach to begin
with ?)

Really appreciate any help.

Jos
xxxxx@philips.com

OSR_Community_User · August 20, 2007, 1:46pm

Welcome to the wonderful(!) world of CD recording software. First, I’d
just like to point out that we have taken a lot of time to help you
avoid dealing with this type of issue. We’ve released a downlevel (to
WinXP) version of IMAPIv2, the optical image mastering API. Details
here:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1974779
http:

This is mostly to help avoid new projects from creeping up. Presuming
that you don’t want to use our solution…

The first cause of the problem you are seeing can occur at the very
start of the write process. Some drives will not start writing until
you “overfill” the buffer once. Thus, you need to send a single extra
write command past that which will fit into the buffer to start the
process going (then wait as the spinup, OPC, etc. occurs).

This problem became much more pronounced with the advent of buffer
underrun free (BUFE bit in Mode Page 2Ah for CD, default for most other
medias) recording. The reason is that, when an underrun condition
occurs and the drive detects that it doesn’t have enough buffer to
continuously write, it will effectively stop writing. See the previous
paragraph for how to get the drive spinning again.

I hope that helps explain the problem you are most likely seeing. Let
us know if this was the cause either way, I’m curious now.

Thanks,

Henry Gabryjelski

Senior Software Development Engineer

US - Windows Device Experience

Microsoft Corporation

From: Jos Scherders [mailto:xxxxx@home.nl]
Sent: Sunday, August 19, 2007 4:55 PM
Subject: MMC Command Read Buffer Capacity

Hi,

I am debugging a problem we have with our own legacy CD Writing software

which fails on certain CD Writers such as the NEC 3540A. The problems
appears to be related to our use of the MMC command Read Buffer Capacity
(We
use TAO writing and the required features are current). Our software
assumes
that if the “Available Length of Buffer” field returned by the Read
Buffer
Capacity command is non-zero we can continue to write and when it is
zero we
should pause.

Problem is that when using this unit it does not work. It always returns

Zero bytes available even when we wait 10-20 seconds. Also, I used an
analyzer to see what a popular commercial CD Writer package does. This
package just keeps writing even when the Read Buffer Capacity returns 0
bytes free.

Can anyone help me with this and explain how the information returned by

Read Buffer Capacity is supposed to be used ? (I am using this to avoid
overflowing the CD writers buffer cache or this the wrong approach to
begin
with ?)

Really appreciate any help.

Jos
xxxxx@philips.com</http:>

OSR_Community_User · August 20, 2007, 3:32pm

Jos,

The whole idea of yours is broken. Consider complete burning algorithm
redesign. Here’s what you need to do step-by-step:

Dump “read buffer capacity” command execution. It will simply fail
on older units (not supported, and you guys

right now rely on the results of this command execution) on some of the
buggy modern units it will case “loss of streaming”

if executed at random places. In any case - THERE’S ABSOLUTELY NO SENSE IN
KNOWNING HOW MUCH OF THE DEVICE

INTERNAL BUFFER IS USED. Except showing to the user fancy progress bar. But
who the .ck cares?

Do not wait for the device. It’s device who should wait for you.
“Write” is blocking command, your DATE OUT information

will be copied to the device internal cache memory (immediately) or
execution will be stalled if buffer is full. In other words:

DON’T BE AFRAID TO OVERFLOW DEVICE’S BUFFER. This is normal and your app
should not notice it.

Build a pipeline. There should be two threads and one FIFO buffer.
One thread should suck the data from the hard disk (or

any other source) into the big SOFTWARE buffer (FIFO), it should be stalled
if the buffer is full (or you may allocate more cache,

just don’t grab too much of the memory or system will go down into deep swap
and this is bad for you), and another thread

should take the data from the FIFO buffer and issue “write” commands to the
device. Finally you have to have something called

“leaky bucket”. So make sure you push data to the FIFO faster then device
does burn.

Good luck! Feel free to ask any questions personally as I’m pretty sure most
of the guys here stay away from burners and rail guns.

Anton

P.S. This is amazing guys writing from @philips.com ask such a questions.
You should have all the specs! It were us who spent half

of our life fining out why Alcohol burns and CloneCD fails. On the same
hardware.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jos Scherders
Sent: Monday, August 20, 2007 2:55 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] MMC Command Read Buffer Capacity

Hi,

I am debugging a problem we have with our own legacy CD Writing software
which fails on certain CD Writers such as the NEC 3540A. The problems
appears to be related to our use of the MMC command Read Buffer Capacity (We

use TAO writing and the required features are current). Our software assumes

that if the “Available Length of Buffer” field returned by the Read Buffer
Capacity command is non-zero we can continue to write and when it is zero we

should pause.

Problem is that when using this unit it does not work. It always returns
Zero bytes available even when we wait 10-20 seconds. Also, I used an
analyzer to see what a popular commercial CD Writer package does. This
package just keeps writing even when the Read Buffer Capacity returns 0
bytes free.

Can anyone help me with this and explain how the information returned by
Read Buffer Capacity is supposed to be used ? (I am using this to avoid
overflowing the CD writers buffer cache or this the wrong approach to begin
with ?)

Really appreciate any help.

Jos
xxxxx@philips.com

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · August 20, 2007, 4:04pm

Are you still using old Roxio code as a basement or is version 2 of the
IMAPI re-written “from the scratch” (as it was supposed to be)?

Thanks!

-a

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry Gabryjelski
Sent: Monday, August 20, 2007 8:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MMC Command Read Buffer Capacity

Welcome to the wonderful(!) world of CD recording software. First, I’d just
like to point out that we have taken a lot of time to help you avoid dealing
with this type of issue. We’ve released a downlevel (to WinXP) version of
IMAPIv2, the optical image mastering API. Details here:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1974779
http:

This is mostly to help avoid new projects from creeping up. Presuming that
you don’t want to use our solution…

The first cause of the problem you are seeing can occur at the very start of
the write process. Some drives will not start writing until you “overfill”
the buffer once. Thus, you need to send a single extra write command past
that which will fit into the buffer to start the process going (then wait as
the spinup, OPC, etc. occurs).

This problem became much more pronounced with the advent of buffer underrun
free (BUFE bit in Mode Page 2Ah for CD, default for most other medias)
recording. The reason is that, when an underrun condition occurs and the
drive detects that it doesn’t have enough buffer to continuously write, it
will effectively stop writing. See the previous paragraph for how to get
the drive spinning again.

I hope that helps explain the problem you are most likely seeing. Let us
know if this was the cause either way, I’m curious now.

Thanks,

Henry Gabryjelski

Senior Software Development Engineer

US - Windows Device Experience

Microsoft Corporation

From: Jos Scherders [mailto:xxxxx@home.nl]
Sent: Sunday, August 19, 2007 4:55 PM
Subject: MMC Command Read Buffer Capacity

Hi,

I am debugging a problem we have with our own legacy CD Writing software
which fails on certain CD Writers such as the NEC 3540A. The problems
appears to be related to our use of the MMC command Read Buffer Capacity (We

use TAO writing and the required features are current). Our software assumes

that if the “Available Length of Buffer” field returned by the Read Buffer
Capacity command is non-zero we can continue to write and when it is zero we

should pause.

Problem is that when using this unit it does not work. It always returns
Zero bytes available even when we wait 10-20 seconds. Also, I used an
analyzer to see what a popular commercial CD Writer package does. This
package just keeps writing even when the Read Buffer Capacity returns 0
bytes free.

Can anyone help me with this and explain how the information returned by
Read Buffer Capacity is supposed to be used ? (I am using this to avoid
overflowing the CD writers buffer cache or this the wrong approach to begin
with ?)

Really appreciate any help.

Jos
xxxxx@philips.com

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</http:>

OSR_Community_User · August 21, 2007, 1:35pm

…

Re-written from scratch. 100% user-mode, in-process (by default) COM
objects. J The only exception is the global CDROM.SYS implementation
of exclusive access via an IOCTL, which is publicly documented and
exposed (and encouraged) for all to use.

There are still optimizations to be made (i.e. option to avoid
intermediate cache for file system image creation), but it’s (imho) a
decent architecture that will expand to support this easily.

Of particular note: We’ve extracted the write engine (which deals with
buffering and dual-thread FIFO buffer management) as a separate
component from the format-specific writers. This makes it easier to add
support for things we (MSFT) haven’t provided support for yet, without
adding in the cost of needing to write that buffer management strategy
yourself. This is good short-term, as we’ve tested a fairly large set
of devices for compatibility. It’s also good long-term, as new devices
will optimize (and simplify) to this command sequence for buffer
management strategy.

I’m on both this list and watching the MSDN forums (noted on the below
link). However, the forums have pretty much the entire IMAPIv2 dev team
available for specific questions. So, ask away at either location! J

Thanks,

Henry Gabryjelski

Senior Software Development Engineer

US - Windows Device Experience

Microsoft Corporation

From: Anton A. Kolomyeytsev [mailto:xxxxx@rocketdivision.com]
Sent: Monday, August 20, 2007 1:04 PM
Subject: RE: MMC Command Read Buffer Capacity

Are you still using old Roxio code as a basement or is version 2 of the
IMAPI re-written “from the scratch” (as it was supposed to be)?

Thanks!

-a

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry
Gabryjelski
Sent: Monday, August 20, 2007 8:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MMC Command Read Buffer Capacity

Welcome to the wonderful(!) world of CD recording software. First, I’d
just like to point out that we have taken a lot of time to help you
avoid dealing with this type of issue. We’ve released a downlevel (to
WinXP) version of IMAPIv2, the optical image mastering API. Details
here:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1974779
http:

This is mostly to help avoid new projects from creeping up. Presuming
that you don’t want to use our solution…

The first cause of the problem you are seeing can occur at the very
start of the write process. Some drives will not start writing until
you “overfill” the buffer once. Thus, you need to send a single extra
write command past that which will fit into the buffer to start the
process going (then wait as the spinup, OPC, etc. occurs).

This problem became much more pronounced with the advent of buffer
underrun free (BUFE bit in Mode Page 2Ah for CD, default for most other
medias) recording. The reason is that, when an underrun condition
occurs and the drive detects that it doesn’t have enough buffer to
continuously write, it will effectively stop writing. See the previous
paragraph for how to get the drive spinning again.

I hope that helps explain the problem you are most likely seeing. Let
us know if this was the cause either way, I’m curious now.

Thanks,

Henry Gabryjelski

Senior Software Development Engineer

US - Windows Device Experience

Microsoft Corporation

From: Jos Scherders [mailto:xxxxx@home.nl]
Sent: Sunday, August 19, 2007 4:55 PM
Subject: MMC Command Read Buffer Capacity

Hi,

I am debugging a problem we have with our own legacy CD Writing software

which fails on certain CD Writers such as the NEC 3540A. The problems
appears to be related to our use of the MMC command Read Buffer Capacity
(We
use TAO writing and the required features are current). Our software
assumes
that if the “Available Length of Buffer” field returned by the Read
Buffer
Capacity command is non-zero we can continue to write and when it is
zero we
should pause.

Problem is that when using this unit it does not work. It always returns

Zero bytes available even when we wait 10-20 seconds. Also, I used an
analyzer to see what a popular commercial CD Writer package does. This
package just keeps writing even when the Read Buffer Capacity returns 0
bytes free.

Can anyone help me with this and explain how the information returned by

Read Buffer Capacity is supposed to be used ? (I am using this to avoid
overflowing the CD writers buffer cache or this the wrong approach to
begin
with ?)

Really appreciate any help.

Jos
xxxxx@philips.com

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</http:>

Maxim_S_Shatskih · August 21, 2007, 4:28pm

> 1) Dump “read buffer capacity” command execution. It will simply fail

on older units (not supported, and you guys

Yes, it is not necessary supported, correct.

From what I remember (sorry, not going in for this kind of code for around a
year) - some drives (maybe all Mt. Fuji drives) just fail WRITE with some
special sense info if the drive’s internal buffer is full.

Other drives do not do this silly thing, and properly pend the write, even if
they cannot accept the data. The data will be auto-accepted later, when the
buffer will become more free, and will be accepted by protocol-level
reconnection transparently to the software.

Nevertheless, some drives seem to want to reduce the hard/firmware complexity,
and just fail such WRITE.

In case of such a failure, it is a good idea to retry WRITE after some time.
Retrying too late means - drop of the data rate, retrying too early - a CPU
waste.

So, the “read buffer capacity” results - if they are sane - can be helpful in
calculating this retry timeout.

This is what I remember off-head, without looking into the actual code.

Maybe Henry and Anton will have more ideas about this.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

OSR_Community_User · August 21, 2007, 5:26pm

Henry,

this is very impressive! As IMAPI v1 was just a piece of crap J How do you
guys handle different hardware support? Some sort

of the XML thing or do you have “spaghetti code” inside the hardware
abstraction layer? In other words: if I know particular

device with broken firmware needs to synchronize cache in synchronous way -
can I add such a support editing text or XML

file or do I need to tell you guys what to so you’d patch your binary code
in the next release?

Anton

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry Gabryjelski
Sent: Tuesday, August 21, 2007 8:34 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MMC Command Read Buffer Capacity

.

Re-written from scratch. 100% user-mode, in-process (by default) COM
objects. J The only exception is the global CDROM.SYS implementation of
exclusive access via an IOCTL, which is publicly documented and exposed (and
encouraged) for all to use.

There are still optimizations to be made (i.e. option to avoid intermediate
cache for file system image creation), but it’s (imho) a decent architecture
that will expand to support this easily.

Of particular note: We’ve extracted the write engine (which deals with
buffering and dual-thread FIFO buffer management) as a separate component
from the format-specific writers. This makes it easier to add support for
things we (MSFT) haven’t provided support for yet, without adding in the
cost of needing to write that buffer management strategy yourself. This is
good short-term, as we’ve tested a fairly large set of devices for
compatibility. It’s also good long-term, as new devices will optimize (and
simplify) to this command sequence for buffer management strategy.

I’m on both this list and watching the MSDN forums (noted on the below
link). However, the forums have pretty much the entire IMAPIv2 dev team
available for specific questions. So, ask away at either location! J

Thanks,

Henry Gabryjelski

Senior Software Development Engineer

US - Windows Device Experience

Microsoft Corporation

From: Anton A. Kolomyeytsev [mailto:xxxxx@rocketdivision.com]
Sent: Monday, August 20, 2007 1:04 PM
Subject: RE: MMC Command Read Buffer Capacity

Are you still using old Roxio code as a basement or is version 2 of the
IMAPI re-written “from the scratch” (as it was supposed to be)?

Thanks!

-a

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry Gabryjelski
Sent: Monday, August 20, 2007 8:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MMC Command Read Buffer Capacity

Welcome to the wonderful(!) world of CD recording software. First, I’d just
like to point out that we have taken a lot of time to help you avoid dealing
with this type of issue. We’ve released a downlevel (to WinXP) version of
IMAPIv2, the optical image mastering API. Details here:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1974779
http:

This is mostly to help avoid new projects from creeping up. Presuming that
you don’t want to use our solution…

The first cause of the problem you are seeing can occur at the very start of
the write process. Some drives will not start writing until you “overfill”
the buffer once. Thus, you need to send a single extra write command past
that which will fit into the buffer to start the process going (then wait as
the spinup, OPC, etc. occurs).

This problem became much more pronounced with the advent of buffer underrun
free (BUFE bit in Mode Page 2Ah for CD, default for most other medias)
recording. The reason is that, when an underrun condition occurs and the
drive detects that it doesn’t have enough buffer to continuously write, it
will effectively stop writing. See the previous paragraph for how to get
the drive spinning again.

I hope that helps explain the problem you are most likely seeing. Let us
know if this was the cause either way, I’m curious now.

Thanks,

Henry Gabryjelski

Senior Software Development Engineer

US - Windows Device Experience

Microsoft Corporation

From: Jos Scherders [mailto:xxxxx@home.nl]
Sent: Sunday, August 19, 2007 4:55 PM
Subject: MMC Command Read Buffer Capacity

Hi,

I am debugging a problem we have with our own legacy CD Writing software
which fails on certain CD Writers such as the NEC 3540A. The problems
appears to be related to our use of the MMC command Read Buffer Capacity (We

use TAO writing and the required features are current). Our software assumes

that if the “Available Length of Buffer” field returned by the Read Buffer
Capacity command is non-zero we can continue to write and when it is zero we

should pause.

Problem is that when using this unit it does not work. It always returns
Zero bytes available even when we wait 10-20 seconds. Also, I used an
analyzer to see what a popular commercial CD Writer package does. This
package just keeps writing even when the Read Buffer Capacity returns 0
bytes free.

Can anyone help me with this and explain how the information returned by
Read Buffer Capacity is supposed to be used ? (I am using this to avoid
overflowing the CD writers buffer cache or this the wrong approach to begin
with ?)

Really appreciate any help.

Jos
xxxxx@philips.com

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</http:>

OSR_Community_User · August 21, 2007, 5:56pm

I have a big piece of the spaghetti code with something like this:

<–

RESTART_EXECUTION: // I know labels are bad but I’m too old to start hating
myself for this…

Status = Write10();

if ( Stutus == “long write in progress” ) { goto RESTART_EXECUTION; }

if ( Status == “not ready & vendor specific” ) { goto RESTART_EXECUTION; }

// ~2 pages of the checks like the ones above

And this is actually what we ask people to pay money for. For the code
issuing write command and making sure
the write data will be delivered to the media. Not for the two-thread FIFO
design Right now PIONEER 1xx line
of the burners is a good example of the device failing write b/c “I’m too
busy, come back later”. And they are
using in maybe 50% of the units as an OEM backbone. Good luck to the
starters. This is not easy money.

Anton

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Tuesday, August 21, 2007 11:28 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MMC Command Read Buffer Capacity

Dump “read buffer capacity” command execution. It will simply fail
on older units (not supported, and you guys

Yes, it is not necessary supported, correct.

From what I remember (sorry, not going in for this kind of code for around a
year) - some drives (maybe all Mt. Fuji drives) just fail WRITE with some
special sense info if the drive’s internal buffer is full.

Other drives do not do this silly thing, and properly pend the write, even
if
they cannot accept the data. The data will be auto-accepted later, when the
buffer will become more free, and will be accepted by protocol-level
reconnection transparently to the software.

Nevertheless, some drives seem to want to reduce the hard/firmware
complexity,
and just fail such WRITE.

In case of such a failure, it is a good idea to retry WRITE after some time.
Retrying too late means - drop of the data rate, retrying too early - a CPU
waste.

So, the “read buffer capacity” results - if they are sane - can be helpful
in
calculating this retry timeout.

This is what I remember off-head, without looking into the actual code.

Maybe Henry and Anton will have more ideas about this.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Maxim_S_Shatskih · August 21, 2007, 6:09pm

> Status = Write10();

if ( Stutus == “long write in progress” ) { goto RESTART_EXECUTION; }

if ( Status == “not ready & vendor specific” ) { goto RESTART_EXECUTION; }

Yes, and I also use the Sleep() calculated based on buffer capacity (if it is
sane).

design Right now PIONEER 1xx line
of the burners is a good example of the device failing write b/c “I’m too
busy, come back later”. And they are
using in maybe 50% of the units as an OEM backbone.

Most laptop units, and have several re-brands (like “Asus”) for desktop.

They are Mt. Fuji.

LG, NEC and Panasonic are MMC.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

OSR_Community_User · August 22, 2007, 12:15pm

Hi Anton,

We’ve worked very hard to find a single code path that works. We
believe we’ve done a very good job of this. We don’t have a hack table,
nor many workarounds in the code, nor any extensibility model.

In addition, the WriteEngine itself has no hacks/workarounds. Our
definition of WriteEngine does not include setup (mode pages, OPC, etc.)
nor finalization (closing tracks/sessions, sync cache, etc.) - it just
does the buffer management during writing. Thus, if we didn’t support a
drive or media type, it would be fairly easy to create an object to
support it:

Setup the mode pages, tracks, etc.
Have our WriteEngine write the LBA ranges.
Perform cleanup tasks as appropriate.

We welcome specific bug reports, via the “optissue at Microsoft” e-mail
address. The more details you provide (INQUIRY data, when it fails,
workarounds if you know them), the more likely that we can integrate a
fix (but never a guarantee).

Hope that helps,

Henry Gabryjelski

Senior Software Development Engineer

US - Windows Device Experience

Microsoft Corporation

From: Anton A. Kolomyeytsev [mailto:xxxxx@rocketdivision.com]
Sent: Tuesday, August 21, 2007 2:25 PM
Subject: RE: MMC Command Read Buffer Capacity

Henry,

this is very impressive! As IMAPI v1 was just a piece of crap J How do
you guys handle different hardware support? Some sort

of the XML thing or do you have “spaghetti code” inside the hardware
abstraction layer? In other words: if I know particular

device with broken firmware needs to synchronize cache in synchronous
way - can I add such a support editing text or XML

file or do I need to tell you guys what to so you’d patch your binary
code in the next release?

Anton

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry
Gabryjelski
Sent: Tuesday, August 21, 2007 8:34 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MMC Command Read Buffer Capacity

…

Re-written from scratch. 100% user-mode, in-process (by default) COM
objects. J The only exception is the global CDROM.SYS implementation
of exclusive access via an IOCTL, which is publicly documented and
exposed (and encouraged) for all to use.

There are still optimizations to be made (i.e. option to avoid
intermediate cache for file system image creation), but it’s (imho) a
decent architecture that will expand to support this easily.

Of particular note: We’ve extracted the write engine (which deals with
buffering and dual-thread FIFO buffer management) as a separate
component from the format-specific writers. This makes it easier to add
support for things we (MSFT) haven’t provided support for yet, without
adding in the cost of needing to write that buffer management strategy
yourself. This is good short-term, as we’ve tested a fairly large set
of devices for compatibility. It’s also good long-term, as new devices
will optimize (and simplify) to this command sequence for buffer
management strategy.

I’m on both this list and watching the MSDN forums (noted on the below
link). However, the forums have pretty much the entire IMAPIv2 dev team
available for specific questions. So, ask away at either location! J

Thanks,

Henry Gabryjelski

Senior Software Development Engineer

US - Windows Device Experience

Microsoft Corporation

From: Anton A. Kolomyeytsev [mailto:xxxxx@rocketdivision.com]
Sent: Monday, August 20, 2007 1:04 PM
Subject: RE: MMC Command Read Buffer Capacity

Are you still using old Roxio code as a basement or is version 2 of the
IMAPI re-written “from the scratch” (as it was supposed to be)?

Thanks!

-a

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry
Gabryjelski
Sent: Monday, August 20, 2007 8:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MMC Command Read Buffer Capacity

Welcome to the wonderful(!) world of CD recording software. First, I’d
just like to point out that we have taken a lot of time to help you
avoid dealing with this type of issue. We’ve released a downlevel (to
WinXP) version of IMAPIv2, the optical image mastering API. Details
here:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1974779
http:

This is mostly to help avoid new projects from creeping up. Presuming
that you don’t want to use our solution…

The first cause of the problem you are seeing can occur at the very
start of the write process. Some drives will not start writing until
you “overfill” the buffer once. Thus, you need to send a single extra
write command past that which will fit into the buffer to start the
process going (then wait as the spinup, OPC, etc. occurs).

This problem became much more pronounced with the advent of buffer
underrun free (BUFE bit in Mode Page 2Ah for CD, default for most other
medias) recording. The reason is that, when an underrun condition
occurs and the drive detects that it doesn’t have enough buffer to
continuously write, it will effectively stop writing. See the previous
paragraph for how to get the drive spinning again.

I hope that helps explain the problem you are most likely seeing. Let
us know if this was the cause either way, I’m curious now.

Thanks,

Henry Gabryjelski

Senior Software Development Engineer

US - Windows Device Experience

Microsoft Corporation

From: Jos Scherders [mailto:xxxxx@home.nl]
Sent: Sunday, August 19, 2007 4:55 PM
Subject: MMC Command Read Buffer Capacity

Hi,

I am debugging a problem we have with our own legacy CD Writing software

which fails on certain CD Writers such as the NEC 3540A. The problems
appears to be related to our use of the MMC command Read Buffer Capacity
(We
use TAO writing and the required features are current). Our software
assumes
that if the “Available Length of Buffer” field returned by the Read
Buffer
Capacity command is non-zero we can continue to write and when it is
zero we
should pause.

Problem is that when using this unit it does not work. It always returns

Zero bytes available even when we wait 10-20 seconds. Also, I used an
analyzer to see what a popular commercial CD Writer package does. This
package just keeps writing even when the Read Buffer Capacity returns 0
bytes free.

Can anyone help me with this and explain how the information returned by

Read Buffer Capacity is supposed to be used ? (I am using this to avoid
overflowing the CD writers buffer cache or this the wrong approach to
begin
with ?)

Really appreciate any help.

Jos
xxxxx@philips.com

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</http:>

OSR_Community_User · August 22, 2007, 5:06pm

Henry,

this is interesting. Thanks to my background I know it’s virtually
impossible to handle such a hardware in the

“generic” way. So you’d better know something I don’t know J If your team
will manage to have proper hardware support

and be friendly to the users’ feedback I think it’s quite possible to make
optical backup integrated into OS core. The only

thing I’d really hate to see it another round of Microsoft Vs. Stacker or
Microsoft Vs. Netscape. This time Microsoft (with the

free burning API) Vs. Padus & Primo & NuMedia & Rocket Division Software
etc.

Thanks!

Anton

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry Gabryjelski
Sent: Wednesday, August 22, 2007 7:14 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MMC Command Read Buffer Capacity

Hi Anton,

We’ve worked very hard to find a single code path that works. We believe
we’ve done a very good job of this. We don’t have a hack table, nor many
workarounds in the code, nor any extensibility model.

In addition, the WriteEngine itself has no hacks/workarounds. Our
definition of WriteEngine does not include setup (mode pages, OPC, etc.) nor
finalization (closing tracks/sessions, sync cache, etc.) - it just does the
buffer management during writing. Thus, if we didn’t support a drive or
media type, it would be fairly easy to create an object to support it:

Setup the mode pages, tracks, etc.
Have our WriteEngine write the LBA ranges.
Perform cleanup tasks as appropriate.

We welcome specific bug reports, via the “optissue at Microsoft” e-mail
address. The more details you provide (INQUIRY data, when it fails,
workarounds if you know them), the more likely that we can integrate a fix
(but never a guarantee).

Hope that helps,

Henry Gabryjelski

Senior Software Development Engineer

US - Windows Device Experience

Microsoft Corporation

From: Anton A. Kolomyeytsev [mailto:xxxxx@rocketdivision.com]
Sent: Tuesday, August 21, 2007 2:25 PM
Subject: RE: MMC Command Read Buffer Capacity

Henry,

this is very impressive! As IMAPI v1 was just a piece of crap J How do you
guys handle different hardware support? Some sort

of the XML thing or do you have “spaghetti code” inside the hardware
abstraction layer? In other words: if I know particular

device with broken firmware needs to synchronize cache in synchronous way -
can I add such a support editing text or XML

file or do I need to tell you guys what to so you’d patch your binary code
in the next release?

Anton

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry Gabryjelski
Sent: Tuesday, August 21, 2007 8:34 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MMC Command Read Buffer Capacity

.

Re-written from scratch. 100% user-mode, in-process (by default) COM
objects. J The only exception is the global CDROM.SYS implementation of
exclusive access via an IOCTL, which is publicly documented and exposed (and
encouraged) for all to use.

There are still optimizations to be made (i.e. option to avoid intermediate
cache for file system image creation), but it’s (imho) a decent architecture
that will expand to support this easily.

Of particular note: We’ve extracted the write engine (which deals with
buffering and dual-thread FIFO buffer management) as a separate component
from the format-specific writers. This makes it easier to add support for
things we (MSFT) haven’t provided support for yet, without adding in the
cost of needing to write that buffer management strategy yourself. This is
good short-term, as we’ve tested a fairly large set of devices for
compatibility. It’s also good long-term, as new devices will optimize (and
simplify) to this command sequence for buffer management strategy.

I’m on both this list and watching the MSDN forums (noted on the below
link). However, the forums have pretty much the entire IMAPIv2 dev team
available for specific questions. So, ask away at either location! J

Thanks,

Henry Gabryjelski

Senior Software Development Engineer

US - Windows Device Experience

Microsoft Corporation

From: Anton A. Kolomyeytsev [mailto:xxxxx@rocketdivision.com]
Sent: Monday, August 20, 2007 1:04 PM
Subject: RE: MMC Command Read Buffer Capacity

Are you still using old Roxio code as a basement or is version 2 of the
IMAPI re-written “from the scratch” (as it was supposed to be)?

Thanks!

-a

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry Gabryjelski
Sent: Monday, August 20, 2007 8:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MMC Command Read Buffer Capacity

Welcome to the wonderful(!) world of CD recording software. First, I’d just
like to point out that we have taken a lot of time to help you avoid dealing
with this type of issue. We’ve released a downlevel (to WinXP) version of
IMAPIv2, the optical image mastering API. Details here:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1974779
http:

This is mostly to help avoid new projects from creeping up. Presuming that
you don’t want to use our solution…

The first cause of the problem you are seeing can occur at the very start of
the write process. Some drives will not start writing until you “overfill”
the buffer once. Thus, you need to send a single extra write command past
that which will fit into the buffer to start the process going (then wait as
the spinup, OPC, etc. occurs).

This problem became much more pronounced with the advent of buffer underrun
free (BUFE bit in Mode Page 2Ah for CD, default for most other medias)
recording. The reason is that, when an underrun condition occurs and the
drive detects that it doesn’t have enough buffer to continuously write, it
will effectively stop writing. See the previous paragraph for how to get
the drive spinning again.

I hope that helps explain the problem you are most likely seeing. Let us
know if this was the cause either way, I’m curious now.

Thanks,

Henry Gabryjelski

Senior Software Development Engineer

US - Windows Device Experience

Microsoft Corporation

From: Jos Scherders [mailto:xxxxx@home.nl]
Sent: Sunday, August 19, 2007 4:55 PM
Subject: MMC Command Read Buffer Capacity

Hi,

I am debugging a problem we have with our own legacy CD Writing software
which fails on certain CD Writers such as the NEC 3540A. The problems
appears to be related to our use of the MMC command Read Buffer Capacity (We

use TAO writing and the required features are current). Our software assumes

that if the “Available Length of Buffer” field returned by the Read Buffer
Capacity command is non-zero we can continue to write and when it is zero we

should pause.

Problem is that when using this unit it does not work. It always returns
Zero bytes available even when we wait 10-20 seconds. Also, I used an
analyzer to see what a popular commercial CD Writer package does. This
package just keeps writing even when the Read Buffer Capacity returns 0
bytes free.

Can anyone help me with this and explain how the information returned by
Read Buffer Capacity is supposed to be used ? (I am using this to avoid
overflowing the CD writers buffer cache or this the wrong approach to begin
with ?)

Really appreciate any help.

Jos
xxxxx@philips.com

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</http:>

OSR_Community_User · August 22, 2007, 5:42pm

Then don’t sue

-p

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Anton A. Kolomyeytsev
Sent: Wednesday, August 22, 2007 2:05 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MMC Command Read Buffer Capacity

Henry,

this is interesting. Thanks to my background I know it’s virtually impossible to handle such a hardware in the
“generic” way. So you’d better know something I don’t know If your team will manage to have proper hardware support
and be friendly to the users’ feedback I think it’s quite possible to make optical backup integrated into OS core. The only
thing I’d really hate to see it another round of Microsoft Vs. Stacker or Microsoft Vs. Netscape. This time Microsoft (with the
free burning API) Vs. Padus & Primo & NuMedia & Rocket Division Software etc.

Thanks!

Anton

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Henry Gabryjelski
Sent: Wednesday, August 22, 2007 7:14 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MMC Command Read Buffer Capacity

Hi Anton,

We’ve worked very hard to find a single code path that works. We believe we’ve done a very good job of this. We don’t have a hack table, nor many workarounds in the code, nor any extensibility model.

In addition, the WriteEngine itself has no hacks/workarounds. Our definition of WriteEngine does not include setup (mode pages, OPC, etc.) nor finalization (closing tracks/sessions, sync cache, etc.) - it just does the buffer management during writing. Thus, if we didn’t support a drive or media type, it would be fairly easy to create an object to support it:

Setup the mode pages, tracks, etc.
Have our WriteEngine write the LBA ranges.
Perform cleanup tasks as appropriate.

We welcome specific bug reports, via the “optissue at Microsoft” e-mail address. The more details you provide (INQUIRY data, when it fails, workarounds if you know them), the more likely that we can integrate a fix (but never a guarantee).

Hope that helps,

Henry Gabryjelski
Senior Software Development Engineer
US - Windows Device Experience
Microsoft Corporation

From: Anton A. Kolomyeytsev [mailto:xxxxx@rocketdivision.com]
Sent: Tuesday, August 21, 2007 2:25 PM
Subject: RE: MMC Command Read Buffer Capacity

Henry,

this is very impressive! As IMAPI v1 was just a piece of crap How do you guys handle different hardware support? Some sort
of the XML thing or do you have “spaghetti code” inside the hardware abstraction layer? In other words: if I know particular
device with broken firmware needs to synchronize cache in synchronous way - can I add such a support editing text or XML
file or do I need to tell you guys what to so you’d patch your binary code in the next release?

Anton

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Henry Gabryjelski
Sent: Tuesday, August 21, 2007 8:34 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MMC Command Read Buffer Capacity

…

Re-written from scratch. 100% user-mode, in-process (by default) COM objects. The only exception is the global CDROM.SYS implementation of exclusive access via an IOCTL, which is publicly documented and exposed (and encouraged) for all to use.

There are still optimizations to be made (i.e. option to avoid intermediate cache for file system image creation), but it’s (imho) a decent architecture that will expand to support this easily.

Of particular note: We’ve extracted the write engine (which deals with buffering and dual-thread FIFO buffer management) as a separate component from the format-specific writers. This makes it easier to add support for things we (MSFT) haven’t provided support for yet, without adding in the cost of needing to write that buffer management strategy yourself. This is good short-term, as we’ve tested a fairly large set of devices for compatibility. It’s also good long-term, as new devices will optimize (and simplify) to this command sequence for buffer management strategy.

I’m on both this list and watching the MSDN forums (noted on the below link). However, the forums have pretty much the entire IMAPIv2 dev team available for specific questions. So, ask away at either location!

Thanks,

Henry Gabryjelski
Senior Software Development Engineer
US - Windows Device Experience
Microsoft Corporation

From: Anton A. Kolomyeytsev [mailto:xxxxx@rocketdivision.com]
Sent: Monday, August 20, 2007 1:04 PM
Subject: RE: MMC Command Read Buffer Capacity

Are you still using old Roxio code as a basement or is version 2 of the IMAPI re-written “from the scratch” (as it was supposed to be)?

Thanks!

-a

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Henry Gabryjelski
Sent: Monday, August 20, 2007 8:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MMC Command Read Buffer Capacity

Welcome to the wonderful(!) world of CD recording software. First, I’d just like to point out that we have taken a lot of time to help you avoid dealing with this type of issue. We’ve released a downlevel (to WinXP) version of IMAPIv2, the optical image mastering API. Details here:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1974779 http:

This is mostly to help avoid new projects from creeping up. Presuming that you don’t want to use our solution…

The first cause of the problem you are seeing can occur at the very start of the write process. Some drives will not start writing until you “overfill” the buffer once. Thus, you need to send a single extra write command past that which will fit into the buffer to start the process going (then wait as the spinup, OPC, etc. occurs).

This problem became much more pronounced with the advent of buffer underrun free (BUFE bit in Mode Page 2Ah for CD, default for most other medias) recording. The reason is that, when an underrun condition occurs and the drive detects that it doesn’t have enough buffer to continuously write, it will effectively stop writing. See the previous paragraph for how to get the drive spinning again.

I hope that helps explain the problem you are most likely seeing. Let us know if this was the cause either way, I’m curious now.

Thanks,

Henry Gabryjelski
Senior Software Development Engineer
US - Windows Device Experience
Microsoft Corporation

From: Jos Scherders [mailto:xxxxx@home.nl]
Sent: Sunday, August 19, 2007 4:55 PM
Subject: MMC Command Read Buffer Capacity

Hi,

I am debugging a problem we have with our own legacy CD Writing software
which fails on certain CD Writers such as the NEC 3540A. The problems
appears to be related to our use of the MMC command Read Buffer Capacity (We
use TAO writing and the required features are current). Our software assumes
that if the “Available Length of Buffer” field returned by the Read Buffer
Capacity command is non-zero we can continue to write and when it is zero we
should pause.

Problem is that when using this unit it does not work. It always returns
Zero bytes available even when we wait 10-20 seconds. Also, I used an
analyzer to see what a popular commercial CD Writer package does. This
package just keeps writing even when the Read Buffer Capacity returns 0
bytes free.

Can anyone help me with this and explain how the information returned by
Read Buffer Capacity is supposed to be used ? (I am using this to avoid
overflowing the CD writers buffer cache or this the wrong approach to begin
with ?)

Really appreciate any help.

Jos
xxxxx@philips.com

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</http:>

OSR_Community_User · August 23, 2007, 2:40pm

Hi Anton,

I definitely hope that our efforts are seen as cooperative, not
competitive. Our data showed that ISV lower filter drivers still cause
a large number of bugchecks for customers. The main reasons for these
filters was a burn engine for CD/DVD recording and exclusive access to
the device.

We knew we couldn’t support every format in our first v2 release, so we
looked at the “pain points”. The buffer management portion of the burn
engine was a major source of pain for ISVs, and could be extracted from
the setup/teardown of the stack. This allows (at ISV option) to move to
our buffer management engine (ICDWriteEngine2).

We also heard loud and clear that some software will want to work apart
from our APIs, and therefore we put into the IOCTL for exclusive access
in CDROM. This allows proper coordination between multiple software,
even if not using IMAPIv2, to gain exclusive access to the device.
Again, this is intended to help remove the filter drivers and thus
improve customer experiences and reduce ISV development and maintenance
costs.

Everything we have provided is fully MSDN documented, and fully opt-in.
If you don’t like the APIs, we don’t even ask for you to use them. On
XP, we don’t even have any shell integration to the IMAPIv2 APIs; That
release (which cost us quite a bit of development and testing) was
solely to remove one reason (downlevel API support to XP/Server 2003)
that ISVs would not be able to migrate to IMAPIv2.

If you have specific concerns, please feel free to e-mail ’ optissue at
Microsoft ’ and start a dialogue.

Thanks,

Henry Gabryjelski

Senior Software Development Engineer

US - Windows Device Experience

Microsoft Corporation

From: Anton A. Kolomyeytsev [mailto:xxxxx@rocketdivision.com]
Sent: Wednesday, August 22, 2007 2:05 PM
Subject: RE: MMC Command Read Buffer Capacity

Henry,

this is interesting. Thanks to my background I know it’s virtually
impossible to handle such a hardware in the

“generic” way. So you’d better know something I don’t know J If your
team will manage to have proper hardware support

and be friendly to the users’ feedback I think it’s quite possible to
make optical backup integrated into OS core. The only

thing I’d really hate to see it another round of Microsoft Vs. Stacker
or Microsoft Vs. Netscape. This time Microsoft (with the

free burning API) Vs. Padus & Primo & NuMedia & Rocket Division Software
etc.

Thanks!

Anton

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry
Gabryjelski
Sent: Wednesday, August 22, 2007 7:14 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MMC Command Read Buffer Capacity

Hi Anton,

We’ve worked very hard to find a single code path that works. We
believe we’ve done a very good job of this. We don’t have a hack table,
nor many workarounds in the code, nor any extensibility model.

In addition, the WriteEngine itself has no hacks/workarounds. Our
definition of WriteEngine does not include setup (mode pages, OPC, etc.)
nor finalization (closing tracks/sessions, sync cache, etc.) - it just
does the buffer management during writing. Thus, if we didn’t support a
drive or media type, it would be fairly easy to create an object to
support it:

Setup the mode pages, tracks, etc.
Have our WriteEngine write the LBA ranges.
Perform cleanup tasks as appropriate.

We welcome specific bug reports, via the “optissue at Microsoft” e-mail
address. The more details you provide (INQUIRY data, when it fails,
workarounds if you know them), the more likely that we can integrate a
fix (but never a guarantee).

Hope that helps,

Henry Gabryjelski

Senior Software Development Engineer

US - Windows Device Experience

Microsoft Corporation

From: Anton A. Kolomyeytsev [mailto:xxxxx@rocketdivision.com]
Sent: Tuesday, August 21, 2007 2:25 PM
Subject: RE: MMC Command Read Buffer Capacity

Henry,

this is very impressive! As IMAPI v1 was just a piece of crap J How do
you guys handle different hardware support? Some sort

of the XML thing or do you have “spaghetti code” inside the hardware
abstraction layer? In other words: if I know particular

device with broken firmware needs to synchronize cache in synchronous
way - can I add such a support editing text or XML

file or do I need to tell you guys what to so you’d patch your binary
code in the next release?

Anton

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry
Gabryjelski
Sent: Tuesday, August 21, 2007 8:34 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MMC Command Read Buffer Capacity

…

Re-written from scratch. 100% user-mode, in-process (by default) COM
objects. J The only exception is the global CDROM.SYS implementation
of exclusive access via an IOCTL, which is publicly documented and
exposed (and encouraged) for all to use.

There are still optimizations to be made (i.e. option to avoid
intermediate cache for file system image creation), but it’s (imho) a
decent architecture that will expand to support this easily.

Of particular note: We’ve extracted the write engine (which deals with
buffering and dual-thread FIFO buffer management) as a separate
component from the format-specific writers. This makes it easier to add
support for things we (MSFT) haven’t provided support for yet, without
adding in the cost of needing to write that buffer management strategy
yourself. This is good short-term, as we’ve tested a fairly large set
of devices for compatibility. It’s also good long-term, as new devices
will optimize (and simplify) to this command sequence for buffer
management strategy.

I’m on both this list and watching the MSDN forums (noted on the below
link). However, the forums have pretty much the entire IMAPIv2 dev team
available for specific questions. So, ask away at either location! J

Thanks,

Henry Gabryjelski

Senior Software Development Engineer

US - Windows Device Experience

Microsoft Corporation

From: Anton A. Kolomyeytsev [mailto:xxxxx@rocketdivision.com]
Sent: Monday, August 20, 2007 1:04 PM
Subject: RE: MMC Command Read Buffer Capacity

Are you still using old Roxio code as a basement or is version 2 of the
IMAPI re-written “from the scratch” (as it was supposed to be)?

Thanks!

-a

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry
Gabryjelski
Sent: Monday, August 20, 2007 8:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MMC Command Read Buffer Capacity

Welcome to the wonderful(!) world of CD recording software. First, I’d
just like to point out that we have taken a lot of time to help you
avoid dealing with this type of issue. We’ve released a downlevel (to
WinXP) version of IMAPIv2, the optical image mastering API. Details
here:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1974779
http:

This is mostly to help avoid new projects from creeping up. Presuming
that you don’t want to use our solution…

The first cause of the problem you are seeing can occur at the very
start of the write process. Some drives will not start writing until
you “overfill” the buffer once. Thus, you need to send a single extra
write command past that which will fit into the buffer to start the
process going (then wait as the spinup, OPC, etc. occurs).

This problem became much more pronounced with the advent of buffer
underrun free (BUFE bit in Mode Page 2Ah for CD, default for most other
medias) recording. The reason is that, when an underrun condition
occurs and the drive detects that it doesn’t have enough buffer to
continuously write, it will effectively stop writing. See the previous
paragraph for how to get the drive spinning again.

I hope that helps explain the problem you are most likely seeing. Let
us know if this was the cause either way, I’m curious now.

Thanks,

Henry Gabryjelski

Senior Software Development Engineer

US - Windows Device Experience

Microsoft Corporation

From: Jos Scherders [mailto:xxxxx@home.nl]
Sent: Sunday, August 19, 2007 4:55 PM
Subject: MMC Command Read Buffer Capacity

Hi,

I am debugging a problem we have with our own legacy CD Writing software

which fails on certain CD Writers such as the NEC 3540A. The problems
appears to be related to our use of the MMC command Read Buffer Capacity
(We
use TAO writing and the required features are current). Our software
assumes
that if the “Available Length of Buffer” field returned by the Read
Buffer
Capacity command is non-zero we can continue to write and when it is
zero we
should pause.

Problem is that when using this unit it does not work. It always returns

Zero bytes available even when we wait 10-20 seconds. Also, I used an
analyzer to see what a popular commercial CD Writer package does. This
package just keeps writing even when the Read Buffer Capacity returns 0
bytes free.

Can anyone help me with this and explain how the information returned by

Read Buffer Capacity is supposed to be used ? (I am using this to avoid
overflowing the CD writers buffer cache or this the wrong approach to
begin
with ?)

Really appreciate any help.

Jos
xxxxx@philips.com

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</http:>

OSR_Community_User · August 23, 2007, 6:47pm

Hi,

Thanks for your response. You can find my reply inline.

Welcome to the wonderful(!) world of CD recording software. First, I’d just like to point out that we have taken a lot of time to help you avoid >dealing with this type of issue. We’ve released a downlevel (to WinXP) version of IMAPIv2, the optical image mastering API. Details here:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1974779

This is mostly to help avoid new projects from creeping up. Presuming that you don’t want to use our solution…

The software I am talking about is dating back from years ago. Since then we are now using software from 3th parties to implement CD/DVD writing because CD/DVD writing is not our core business (I actually work for Philips Medical Systems and not the consumer branch). If I would have known that this solution was available from Microsoft we definitely would have taken a look at it. We actually did extensice research and pilot projects in this area including Nero, Sonic and others but I must have missed this one :(( Either way, I definitly will have a look at it.

The first cause of the problem you are seeing can occur at the very start of the write process. Some drives will not start writing until you >“overfill” the buffer once. Thus, you need to send a single extra write command past that which will fit into the buffer to start the process going >(then wait as the spinup, OPC, etc. occurs).

I think this was in fact the problem. After filling the buffer, plus a few more writes, the unit would return a non-zero value in response to Read Buffer Capacity. These extra writes is what caused my confusion and made me realise something is seriously wrong in how this was implemented.

What do you mean with "wait as the spinup, OPC etc occurs. I assume my writes either succeed or return the proper SENSE info (e.g. to tell me to wait and retry). Is that what you mean as well or am I missing something ?

Thanks again,

Jos

OSR_Community_User · August 23, 2007, 7:11pm

Hi Anton,
Jos,

The whole idea of yours is broken. Consider complete burning algorithm
redesign. >Here’s what you need to do step-by-step:

I was using the Read Buffer Command two reasons (both of which are wrong I
now know). The MMC spec says that this command returns the minimum number of
bytes available in the unit’s buffer. I took this to mean “don’t write more
then whatever is returned in the bytes available field”. The word “minimum”
is curious here and I still have no idea what they mean with it.

And yes, I will have to “some” rework :((

Good luck! Feel free to ask any questions personally as I’m pretty sure
most of the >guys here stay away from burners and rail guns.

Thanks a lot. Why didn’t I sent this question to this excellent mailing list
a while ago ? :))

P.S. This is amazing guys writing from @philips.com ask such a questions.
You should have all the specs! It were us who spent half
of our life fining out why Alcohol burns and CloneCD fails. On the same
hardware.

I am afraid I have to agree with you here but as long as management expects
software developers (in fact only 1) to write CD/DVD software in 1 - 2
months I dont think you can expect much. Besides, the number of different
units we have to suppoer is very limited as we control both hardware and
software configuration of the systems on which it runs. (Which is good for
us for all the wrong reasons:))

Anyway, really appreciate your detailed and most interesting responds. Back
to work :))

Jos

Tim_Roberts · August 23, 2007, 7:25pm

Jos Scherders wrote:

P.S. This is amazing guys writing from @philips.com ask such a
questions. You should have all the specs! It were us who spent half
of our life fining out why Alcohol burns and CloneCD fails. On the
same hardware.

Philips is a very, very large company. You would not expect every Intel
employee to know all of the SSE2 opcodes, would you?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

OSR_Community_User · August 23, 2007, 7:29pm

Hi,

I have a big piece of the spaghetti code with something like this:

<–

RESTART_EXECUTION: // I know labels are bad but I’m too old to start
hating
myself for this…

Status = Write10();

if ( Stutus == “long write in progress” ) { goto RESTART_EXECUTION; }

if ( Status == “not ready & vendor specific” ) { goto RESTART_EXECUTION; }

// ~2 pages of the checks like the ones above

This reminds why I actually decided that using Read Buffer Capacity was a
great idea (how stupid can you be). The question I asked myself was “Can I
make sure that I don’t run into a situation where I write the data faster
then the unit can consume it ?”. This would avoid any problems with a unit
failing writes and having to deal with that. After checking the MMC manuals
I figured that Read Buffer Cap was the answer to my question. WRONG :))

Jos.

OSR_Community_User · August 24, 2007, 4:37am

Where did you find me telling this? I’ve only told it’s easier to get NDA
protected or even paid
specs if you work for the company who release 'em.

-a

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, August 24, 2007 2:25 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] MMC Command Read Buffer Capacity

Jos Scherders wrote:

P.S. This is amazing guys writing from @philips.com ask such a
questions. You should have all the specs! It were us who spent half
of our life fining out why Alcohol burns and CloneCD fails. On the
same hardware.

Philips is a very, very large company. You would not expect every Intel
employee to know all of the SSE2 opcodes, would you?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · August 24, 2007, 4:42am

Start writing the code, grab ~20 units from the local PC store. Start
testing the code. It will fail in
constant places with fixed number of the codes. In 2-3 days you’ll have 90%
device support. Last 10% will go
for rare and EOL-ed units and it will be your customers who’ll sit on your
back telling you “would you
finally PLEASE fix this for us?”. In probably 5 years you’ll have more or
less stable code.

-a

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jos Scherders
Sent: Friday, August 24, 2007 2:29 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] MMC Command Read Buffer Capacity

Hi,

I have a big piece of the spaghetti code with something like this:

<–

RESTART_EXECUTION: // I know labels are bad but I’m too old to start
hating
myself for this…

Status = Write10();

if ( Stutus == “long write in progress” ) { goto RESTART_EXECUTION; }

if ( Status == “not ready & vendor specific” ) { goto RESTART_EXECUTION; }

// ~2 pages of the checks like the ones above

This reminds why I actually decided that using Read Buffer Capacity was a
great idea (how stupid can you be). The question I asked myself was “Can I
make sure that I don’t run into a situation where I write the data faster
then the unit can consume it ?”. This would avoid any problems with a unit
failing writes and having to deal with that. After checking the MMC manuals
I figured that Read Buffer Cap was the answer to my question. WRONG :))

Jos.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

David_J_Craig · August 24, 2007, 12:10pm

I am still surprised at how incompatible so many CD/DVD devices are even
though the MMC spec has been out for over ten years. I know that several
years ago we used a third party burning library for a product because so
many devices were non-standard. Of course the specs for the various optical
media formats are expensive and there are so many of them - Orange, White,
Blue, etc. I have forgotten most of what I learned, but decided it was for
the few who specialize in this stuff.

–
David J. Craig
Engineer, Sr. Staff Software Systems
Broadcom Corporation

“Anton A. Kolomyeytsev” wrote in message
news:xxxxx@ntdev…
> Start writing the code, grab ~20 units from the local PC store. Start
> testing the code. It will fail in
> constant places with fixed number of the codes. In 2-3 days you’ll have
> 90%
> device support. Last 10% will go
> for rare and EOL-ed units and it will be your customers who’ll sit on your
> back telling you “would you
> finally PLEASE fix this for us?”. In probably 5 years you’ll have more or
> less stable code.
>
> -a
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Jos Scherders
> Sent: Friday, August 24, 2007 2:29 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] MMC Command Read Buffer Capacity
>
> Hi,
>
>>I have a big piece of the spaghetti code with something like this:
>>
>> <–
>>
>> RESTART_EXECUTION: // I know labels are bad but I’m too old to start
>> hating
>> myself for this…
>>
>> Status = Write10();
>>
>> if ( Stutus == “long write in progress” ) { goto RESTART_EXECUTION; }
>>
>> if ( Status == “not ready & vendor specific” ) { goto
>> RESTART_EXECUTION; }
>>
>> // ~2 pages of the checks like the ones above
>>
>
> This reminds why I actually decided that using Read Buffer Capacity was a
> great idea (how stupid can you be). The question I asked myself was “Can I
> make sure that I don’t run into a situation where I write the data faster
> then the unit can consume it ?”. This would avoid any problems with a
> unit
> failing writes and having to deal with that. After checking the MMC
> manuals
> I figured that Read Buffer Cap was the answer to my question. WRONG :))
>
> Jos.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>