On Sun, 07 Sep 2003 00:59:23 +0200 Andy Polyakov <[EMAIL PROTECTED]> wrote: > <snip>. But as long as NEC hides behind > "designed exclusively for Windows" and keep providing Windows software > which applies packet writing strategy even to DVD+RW, you won't be > able to make them address the problem "by the root" so to say. > Unfortunately:-(
To be fair to NEC, they didn't provide me with any Windows software that does this. They didn't provide any software at all. > <snip> > I/O to /dev/scdN passes through common block buffer, which is free to > rearrange the requests. E.g. I could observe 'dd of=/dev/scdN obs=32k' > being rearranged as a serie of 126K requests. At the beginning of > recording that is. As recording is normally way slower than dd, block > buffer starts starving for memory at some point and starts fragmenting > at 2K, 4K, 14K, 31K, literally whatever chunksizes, which by the way > can even appear in *non-ascending* order. This is confusing for your > firmware. /dev/raw/rawM on the other hand maintains the strict order > and fragmentation implied by the writing program. In other words 'dd > of=/dev/raw/rawM obs=32k' results in serie of 32K requests in strictly > asceding order. Something your firmware can bear with. I've modified the CDRW packet writing patch http://w1.894.telia.com/~u89404340/patches/packet/2.4/packet-2.4.21.patch.bz2 to work in combination with your patch to write to DVD+RWs. This works: it looks like the DVD writer is happy so long as I only feed it with 32k requests. But the performance is dreadful. If I can manage to get any sort of reasonable performance out of this, I'll send you what I've done. Thanks, John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
