> >> > mt = per*(bsize/secsize)/100 * 1000 / secsps/s; > >> >to > >> > mt = (per-50)*(bsize/secsize)/100 * 1000 / secsps/s; > >> > >> Did it help? > > >Yes, it seems so... BTW I've added call to cdr_buffer_cap right > >after usleep and here is what I get (I print the return value from > >cdr_buffer_cap). > > So I assume that 1.11a40pre2 will work "out of the box"
I'd assume so... > BTW: did you need this feature on your system? If the question is if I have a disk and burner unit on the same channel, then the answer is yes. I have single IDE controller and 3 disks and 1 burner unit. Do I use that disk as source for burning? Yes, 1/3 of times. Do I absolutely need this feature? I had no problems without it, without usleep that is. I find -immed extremely valueable and [in my opinion] it even deserves to be auto-engaged as drafted in my earlier post in reply to 1.11a35 announcement, see http://www.mail-archive.com/[email protected]/msg03483.html. If the question is really about "If it turns out that it would make sense to have a separate option for the the wait feature, write to the author and convince him," then you already know my opinion. I still consider that two distinct options should be provided. As you've introduced minbuf now, then why not associate usleep-ing with it, instead of -immed that is? As for more general feedback. I find following paragraph misleading: ... tell cdrecord to try to wait short times wile writing to the media. This is expected to free the IDE bus if the CD/DVD writer and the data source are connected to the same IDE cable. In this case, the CD/DVD writer would otherwise usually block the IDE bus for nearly all the time making it impossi� ble to fetch data from the source drive. It's not really-really about releasing the IDE channel for those times, but about responsiveness of the system during burning, primarily toward the process that reads the data from the disk. You don't suffer from a deadlock condition, do you? The worst that can happen is that the reader process doesn't get a fair chance to squeeze in read requests to disk [but it's not like it can't squeeze them at all] and you'll suffer from buffer underrun, right? At the very least *if* a deadlock was actually an issue, then you would have to fall asleep after *each* write operation and not after each transferred MB. Well, probably not fall asleep (too short interval), but at least yield the control over CPU. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
