Re: [Cdrecord-support] Re: [Cdrecord-developers] Re: [Cdrecord-video] Re: cdrtools-2.01.01a09 released
"Hendrik Visage" <hvisage@envisage.co.za> writes:
> On 5/30/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
>> Bill Davidsen <davidsen@tmr.com> wrote:
>>
>> > I wouldn't live in the past if you would get the hint that SCSI is dead
>> > for probably 98% of your users, and trying to use connections which
>> > depent on the fantasy that the devices are scsi is a source of endless
>> > grief. Only the commands are (sort of) scsi, the transport is almost
>> > entirely gone for CD/DVD.
>>
>> Each time you repeat this nonsense, I foster the impression that you are
>> not only living in the past but that you are also uneducatable :-(
>
> Bill, Although I have issues with the way how Joerg comes over (it
> might be a cultural thing from a person that's typing in a non-mother
> tongue), I have to start to agree with Joerg on this one.
Well -- overboarding self-esteem is frowned upon in Germany, too.
> Not only this Bill, but that the CD writers still use a SCSI based
> protocol (and they came out initially in SCSI before IDE could handle
> the *sustained* throughput).
Well, it's not as though IDE had difficulties feeding 300 kB/s over the
cable - that works even in PIO0.
> Even worst is that in certain situations I've found that a CD/DVD
> writer don't wnat *any*thing else on the same IDE cable that's trying
> to talk when that CD/DVD writer is writing.
It's a timing and perhaps device locking issue, mostly.
If the other device blocks the bus during an eject command, it's no
wonder the first complains with buffer underrun. And this still doesn't
justify making ATA look like SCSI.
I can as well show a SCSI eject command block the bus for long enough to
trigger buffer underruns, so your case isn't specific to IDE.
--
Matthias Andree
Reply to: