[Romeo Rondeau[_4_]]

Mike Rivers wrote:
wrote:
****, I was doing my tape deck maintenance , I have no real training
I was just doing what my internet friend said to do
when demagnitizing the heads I brought the demag unit too close and
now my heads won't record.
I have a band coming in tonight, HELP

I'd suggest that you push your tape deck into the landfill and get a
computer. You can have thousands of tracks and all you need to do is get
all the pieces together to make it work. You shouldn't have any problem
doing that by tonight. You can buy the parts at just about any music
store and when it doesn't work, your Internet friends will tell you
where you went wrong and that "everybody knows that."


Hey Mike! Ever try Decaf? :-)

[Mike Rivers]

wrote:

I do not agree with the jest of this. Audio is too specific for any
ordinary computer nerd!!!
They are not trained to be able to grab the gist of the needs involved
with DAW.

You could be right about this. It seems that the makers' criteria for a
Firewire port is that it works for transferring data from a video camera
to the computer. No requirement for real time or continuous transfer,
yet those are the things that we, as audio people, try to use it for.
Maybe it's us that aren't very smart. Who ever thought of using Firewire
for audio transit anyway? Maybe Dan Lavry is right (but I can't quote
you his argument against it).

Just examine all the software/hardware creators who have offered their
own digital audio.

Oy! The amount of new audio hardware and software that looks like the
designer never worked in a studio. Sure, it's functional, but it
requires breaking 50 years of workflow habits. The D'Vorak keyboard, I'm
told by dedicated users, has it all over the QWERTY but you don't see
people swarming to it - because they don't have to. With audio, it's
their way of the highway.

Now ask Scott which one's actually work in a transparent fashion!!
You did not design or build your own mixing console, you researched
the bought a quality product from a reliable dealer!

I bought my mixing console in 1985 where there were fewer choices
(actually about the same number of choices that we have today, missing
the 20 years in the middle where there were a number of 24 channel 8-bus
recording board on the market) so it was pretty easy to make the choice.
And in fact, a big influence on my choice wasn't sound quality, but that
it was a Soundcraft. Since I was buying it for a remote truck where
probably half the engineering work would be done by others than me, I
figured that buying a Soundcraft was kind of like buying a Toyota - it's
pretty good overall, there's no reason not to like it, and given that
few would have mixed on it since it was a new model at the time (a 600)
they'd have confidence in it because it's a Soundcraft. The fact that it
has a traditional layout and anyone familiar with a console could use it
without a lot of explanation. If I was making a similar decision today,
it would pretty surely be ProTools, for the same reasons.

what gives you the idea that you should design and build your own
digital mixing board?

Nothing. I didn't say that. But if I were to get a computer-based DAW,
unless I bought a turnkey system from a trusted integrator, I'd be
building my own recorder and mixer, including input and output stages
and user interface based largely on hardware (the computer) that wasn't
designed for audio recording and processing. That's what I meant.

I have a Mackie HDR24/96, which has much of the guts of a PC inside, but
it has dedicated interface hardware and user interface, all designed to
work together and tested for usability, stability, and reliability. They
did a pretty good job, and there are even some parts that I can replace
if need be. But not everything, and sadly, it's extinct. But while I can
replace ICs, transistors, resistors, and capacitors in my Soundcraft
console, I would probably have a hard time replacing switches. Nothing's
perfect.

or that a computer nerd should have that technical expertise.

I might be able to write reasonably sufficient functional specifications
that a computer nerd could use as a guide for choosing components, and
he could test his integration before giving it to me.

the BLONDE says
It is a computer-right, it uses an operating system-right, so what is
the difference???
Hank says
The hardware side of computer-centric digital audio work often presents
a morass of potential combinations of chips and protocols and odds
for/against successful operation

And Hank would be correct. He should send that post in to the Letters
column of Mix Magazine.

--
If you e-mail me and it bounces, use your secret decoder ring and reach
me he
double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers
)

[Laurence Payne[_2_]]

On Fri, 12 Sep 2008 22:04:38 GMT, Mike Rivers
wrote:

It seems that the makers' criteria for a
Firewire port is that it works for transferring data from a video camera
to the computer. No requirement for real time or continuous transfer,
yet those are the things that we, as audio people, try to use it for.

Is it all that different? You transfer video from a dv camera by
rolling the tape. Then an amount of data equivilent to quite a few
tracks of audio streams down the Firewire link. Maybe it's a bit
different for cameras that record to internal optical disk, and I
believe quality cameras with solid-state storage are appearing. But
the original generation was all tape and Firewire coped very nicely.

[Richard Crowley]

"Mike Rivers" wrote ...
wrote:
I do not agree with the jest of this. Audio is too specific for any
ordinary computer nerd!!!
They are not trained to be able to grab the gist of the needs involved
with DAW.

You could be right about this. It seems that the makers' criteria for a
Firewire port is that it works for transferring data from a video camera
to the computer. No requirement for real time or continuous transfer,

Firewire transfer of video (primarily "DV") is *very much* both REAL-
TIME and CONTINUOUS-TRANSFER in every sense of both terms.
Transfer either from a camcorder or VCR to a computer happens in the
actual real-time of the video playback. Indeed, you can monitor the video
on any standard TV screen.

And conversely, transfer from a computer back out to a camcorder/
VCR also happens *continuously* in *real-time* for the simple reason
that general-purpose consumer and pro camcorders/VCRs simply
don't operate at any other speed when recording.

Once the tape starts rolling, there's no provision for the computer
to say "I missed frame 01:52:35:14, can you please re-transmit it?"

OTOH, for Flash memory or hard-drive based camcorders,
it is virtually identical to any common asynchronous file transfer,
as you would do from a USB thumb drive. That indeed is why
most Flash and hard-drive based camcorders use USB 2 rather
than Firewire. And many of them are configured to look exactly
like an external mass storage device (hard drive, etc.) to the user's
computer, so that "capture" or "ingest" is literally "drag-n-drop" file
copy.

Certainly, there are specialty devices that record and playback
video at higher or lower than real-time speeds, but that entire
genre of equipment is well outside the limits of anything that would
typically use Firewire (or USB, for that matter). Indeed, it is
usually the kind of thing that you would rent rather than even own.

yet those are the things that we, as audio people, try to use it for.
Maybe it's us that aren't very smart. Who ever thought of using Firewire
for audio transit anyway?

I can't see any fundamental reason why equivalent (25Mb/sec)
bandwidth couldn't contain either video or audio (or, indeed
anything else). Firewire was originally designed for iso-synchronous
*real-time* and *continuous* transfer, primarily for use with
digital video. But again, there's no fundamental reason the same
bandwidth couldn't contain several channels of audio, etc.

Here, I'm talking about specifically multi-track recording, as from
a live preformance. When we start taking about selective tracks
and requirements for minimal-latency monitoring of previously-
recorded tracks, that is as much a function of the hardware and
software on the computer as it is for the interconnect scheme.

Maybe Dan Lavry is right (but I can't quote you his argument against it).

Can you at least make a reference to it? So far, it sounds like
while Mr. Lavry might be an analog and A/D genius, he has
great gaps of understanding of how modern digital interconnects
work. What you have explained so far is complete nonsensical
gobbeldygook

Just examine all the software/hardware creators who have offered their
own digital audio.

Because there is no widely-accepted multi-track audio standard
such as there is for video (i.e. DV25 via Firewire) or for 2-track
audio (AES/EBU, close kin to SPDIF/Toslink)

[Richard Crowley]

"Richard Crowley" wrote...
Because there is no widely-accepted multi-track audio standard
such as there is for video (i.e. DV25 via Firewire) or for 2-track
audio (AES/EBU, close kin to SPDIF/Toslink)

The closest there is may be the Alesis 8-channel ADAT optical
interconnect standard which has been implemented rather beyond
the original application.

MADI appears to be a physical as well as logical definition, so it
doesn't fall within the discussion of transport streams that could be
implemented on Firewire or USB, etc.

[[email protected]]

On Sep 12, 6:04 pm, Mike Rivers wrote:
wrote:
I do not agree with the jest of this. Audio is too specific for any
ordinary computer nerd!!!
They are not trained to be able to grab the gist of the needs involved
with DAW.

You could be right about this. It seems that the makers' criteria for a
Firewire port is that it works for transferring data from a video camera
to the computer. No requirement for real time or continuous transfer,
yet those are the things that we, as audio people, try to use it for.
Maybe it's us that aren't very smart. Who ever thought of using Firewire
for audio transit anyway? Maybe Dan Lavry is right (but I can't quote
you his argument against it).

Just examine all the software/hardware creators who have offered their
own digital audio.

Oy! The amount of new audio hardware and software that looks like the
designer never worked in a studio. Sure, it's functional, but it
requires breaking 50 years of workflow habits. The D'Vorak keyboard, I'm
told by dedicated users, has it all over the QWERTY but you don't see
people swarming to it - because they don't have to. With audio, it's
their way of the highway.

Now ask Scott which one's actually work in a transparent fashion!!
You did not design or build your own mixing console, you researched
the bought a quality product from a reliable dealer!

I bought my mixing console in 1985 where there were fewer choices
(actually about the same number of choices that we have today, missing
the 20 years in the middle where there were a number of 24 channel 8-bus
recording board on the market) so it was pretty easy to make the choice.
And in fact, a big influence on my choice wasn't sound quality, but that
it was a Soundcraft. Since I was buying it for a remote truck where
probably half the engineering work would be done by others than me, I
figured that buying a Soundcraft was kind of like buying a Toyota - it's
pretty good overall, there's no reason not to like it, and given that
few would have mixed on it since it was a new model at the time (a 600)
they'd have confidence in it because it's a Soundcraft. The fact that it
has a traditional layout and anyone familiar with a console could use it
without a lot of explanation. If I was making a similar decision today,
it would pretty surely be ProTools, for the same reasons.

what gives you the idea that you should design and build your own
digital mixing board?

Nothing. I didn't say that. But if I were to get a computer-based DAW,
unless I bought a turnkey system from a trusted integrator, I'd be
building my own recorder and mixer, including input and output stages
and user interface based largely on hardware (the computer) that wasn't
designed for audio recording and processing. That's what I meant.

I have a Mackie HDR24/96, which has much of the guts of a PC inside, but
it has dedicated interface hardware and user interface, all designed to
work together and tested for usability, stability, and reliability. They
did a pretty good job, and there are even some parts that I can replace
if need be. But not everything, and sadly, it's extinct. But while I can
replace ICs, transistors, resistors, and capacitors in my Soundcraft
console, I would probably have a hard time replacing switches. Nothing's
perfect.

or that a computer nerd should have that technical expertise.

I might be able to write reasonably sufficient functional specifications
that a computer nerd could use as a guide for choosing components, and
he could test his integration before giving it to me.

the BLONDE says
It is a computer-right, it uses an operating system-right, so what is
the difference???
Hank says
The hardware side of computer-centric digital audio work often presents
a morass of potential combinations of chips and protocols and odds
for/against successful operation

And Hank would be correct. He should send that post in to the Letters
column of Mix Magazine.

--
If you e-mail me and it bounces, use your secret decoder ring and reach
me he
double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers
)

or you could do like Hank did
get a mac and 3 metric halo 2882
24 track track firewire that works!!!! and sounds great!!!!
custom built computer/OS with a I/O that is designed for that
system!!!!!

[[email protected]]

On Sep 12, 6:04 pm, Mike Rivers wrote:
wrote:
I do not agree with the jest of this. Audio is too specific for any
ordinary computer nerd!!!
They are not trained to be able to grab the gist of the needs involved
with DAW.

You could be right about this. It seems that the makers' criteria for a
Firewire port is that it works for transferring data from a video camera
to the computer. No requirement for real time or continuous transfer,
yet those are the things that we, as audio people, try to use it for.
Maybe it's us that aren't very smart. Who ever thought of using Firewire
for audio transit anyway? Maybe Dan Lavry is right (but I can't quote
you his argument against it).

Just examine all the software/hardware creators who have offered their
own digital audio.

Oy! The amount of new audio hardware and software that looks like the
designer never worked in a studio. Sure, it's functional, but it
requires breaking 50 years of workflow habits. The D'Vorak keyboard, I'm
told by dedicated users, has it all over the QWERTY but you don't see
people swarming to it - because they don't have to. With audio, it's
their way of the highway.

Now ask Scott which one's actually work in a transparent fashion!!
You did not design or build your own mixing console, you researched
the bought a quality product from a reliable dealer!

I bought my mixing console in 1985 where there were fewer choices
(actually about the same number of choices that we have today, missing
the 20 years in the middle where there were a number of 24 channel 8-bus
recording board on the market) so it was pretty easy to make the choice.
And in fact, a big influence on my choice wasn't sound quality, but that
it was a Soundcraft. Since I was buying it for a remote truck where
probably half the engineering work would be done by others than me, I
figured that buying a Soundcraft was kind of like buying a Toyota - it's
pretty good overall, there's no reason not to like it, and given that
few would have mixed on it since it was a new model at the time (a 600)
they'd have confidence in it because it's a Soundcraft. The fact that it
has a traditional layout and anyone familiar with a console could use it
without a lot of explanation. If I was making a similar decision today,
it would pretty surely be ProTools, for the same reasons.

what gives you the idea that you should design and build your own
digital mixing board?

Nothing. I didn't say that. But if I were to get a computer-based DAW,
unless I bought a turnkey system from a trusted integrator, I'd be
building my own recorder and mixer, including input and output stages
and user interface based largely on hardware (the computer) that wasn't
designed for audio recording and processing. That's what I meant.

I have a Mackie HDR24/96, which has much of the guts of a PC inside, but
it has dedicated interface hardware and user interface, all designed to
work together and tested for usability, stability, and reliability. They
did a pretty good job, and there are even some parts that I can replace
if need be. But not everything, and sadly, it's extinct. But while I can
replace ICs, transistors, resistors, and capacitors in my Soundcraft
console, I would probably have a hard time replacing switches. Nothing's
perfect.

or that a computer nerd should have that technical expertise.

I might be able to write reasonably sufficient functional specifications
that a computer nerd could use as a guide for choosing components, and
he could test his integration before giving it to me.

the BLONDE says
It is a computer-right, it uses an operating system-right, so what is
the difference???
Hank says
The hardware side of computer-centric digital audio work often presents
a morass of potential combinations of chips and protocols and odds
for/against successful operation

And Hank would be correct. He should send that post in to the Letters
column of Mix Magazine.

--
If you e-mail me and it bounces, use your secret decoder ring and reach
me he
double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers
)

or you could do like Hank did
get a mac and 3 metric halo 2882
24 track track firewire that works!!!! and sounds great!!!!
custom built computer/OS with a I/O that is designed for that
system!!!!!

[Mike Rivers]

Romeo Rondeau wrote:

Hey Mike! Ever try Decaf? :-)

Once, but it kept me awake.

--
If you e-mail me and it bounces, use your secret decoder ring and reach
me he
double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers
)

[Mike Rivers]

Laurence Payne wrote:

Is it all that different? You transfer video from a dv camera by
rolling the tape.

You don't copy a file? And if something goes amuck, you repeat it. I
guess I must be ahead of the times.

believe quality cameras with solid-state storage are appearing. But
the original generation was all tape and Firewire coped very nicely.

You mean the people who use video cameras actually suffered with a real
time transfer? Audio people would never stand for that. This is why we
have all of these anti-piracy schemes. If people had to spend an hour to
copy a CD, they wouldn't do it.



--
If you e-mail me and it bounces, use your secret decoder ring and reach
me he
double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers
)

[Mike Rivers]

Richard Crowley wrote:

Once the tape starts rolling, there's no provision for the computer
to say "I missed frame 01:52:35:14, can you please re-transmit it?"

OTOH, for Flash memory or hard-drive based camcorders,
it is virtually identical to any common asynchronous file transfer,
as you would do from a USB thumb drive.

My apologies. I didn't realize that those old technology tape based
cameras used Firewire. I thought it was something that came along with
the new solid state ones. Well, OK, maybe they DO make an effort to get
that transfer right. But while there may be a similar number of bits per
second as with multitrack audio, I'll bet the criteria for accuracy is
different. Video has all sorts of correction for dropped data built in
because it's always had to deal with it. And also, we can accept a
little glitch in video easier than we can accept a little glitch in
audio (I'm talking the hobbyist "we" not the professional "we" who
somehow seem to have systems that work - because they're engineered by
professionals and cost professional prices.

Here, I'm talking about specifically multi-track recording, as from
a live preformance. When we start taking about selective tracks
and requirements for minimal-latency monitoring of previously-
recorded tracks, that is as much a function of the hardware and
software on the computer as it is for the interconnect scheme.

I'm impressed that it works as well as it does, and don't get me wrong -
I'm not one of the naysayers who say it doesn't or can't (like a
bumblebee can't fly). But given the large number of people who have
trouble getting it to work without glitches, there must be something
about either the interface or some other part of the system that isn't
working as it should. It's easy to argue that because some systems work
fine, they all should. So why don't they? Probably because there's some
incompatibility between an unlucky choice of components. The fact that
this is possible with a standard to define the interface says that
there's something wrong somewhere.

Maybe Dan Lavry is right (but I can't quote you his argument against it).
Can you at least make a reference to it?

I have only a fuzzy recollection of a chat we had at last year's AES
show. I asked him if he had a Firewire interface planned and he went off
on how Firewire can't provide accurate enough timing for multitrack
audio. The Lynx guys DO have a Firewire option for their multi-channel
converters but they told me that they built it because the customers
asked for it and they managed to do a decent job. But that their AES/EBU
setup that goes to a PCI card is superior.

Because there is no widely-accepted multi-track audio standard
such as there is for video (i.e. DV25 via Firewire) or for 2-track
audio (AES/EBU, close kin to SPDIF/Toslink)

Or analog tape.

--
If you e-mail me and it bounces, use your secret decoder ring and reach
me he
double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers
)

[Scott Dorsey]

hank alrich wrote:
wrote:

You did not design or build your own mixing console, you researched
the bought a quality product from a reliable dealer!

Actually, we did. We didn't design IC's, transistors, caps, etc., but we
did design and build the boards, three of 'em, to wind up with the
systems we had at onion audio inside Armadillo World Headquarters back
in the '70's.

That used to be a standard thing.... folks built their own custom gear
to suit how they worked in the studio.

I don't understand why folks aren't doing it today with software, especially
as software is a lot easier to change.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Mike Rivers]

wrote:

or you could do like Hank did
get a mac and 3 metric halo 2882
24 track track firewire that works!!!! and sounds great!!!!
custom built computer/OS with a I/O that is designed for that
system!!!!!

But I already have a Mackie HDR24/96. Why switch to a system that
requires me to carry a computer (at minimum, two pieces - a laptop
computer and power supply) and three rack-mount interface boxes, plus
cables, plus software and the decisions that go along with that?

I had virtually no learning curve when I started using the Mackie. Of
course there was more to learn than arming the tracks and pushing the
Record button, but you could make recordings knowing only that much. No
system to assemble, no software to choose, load, register, and unlock
(and learn). I've not run across a DAW editor that's as intuitive and
easy to use as the Mackie, and it didn't take very long to learn how to
use that. Sure, I can make dozens of different kinds of edits in Sequoia
or Wavelab, but 98% of the time a simple edit with the default crossfade
time works just fine. And I can tweak the Mackie edits shouid I need to.
I don't have plug-in processing available on every track, true, but then
I didn't work that way when I used tape, and I still have my hardware
compressors, EQs, and reverbs. And I have people I can send clients to
if their projects require a full-out DAW treatment. I get bored working
on that sort of project anyway.



--
If you e-mail me and it bounces, use your secret decoder ring and reach
me he
double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers
)

[Richard Crowley]

"Mike Rivers" wrote ...
But while there may be a similar number of bits per second as with
multitrack audio, I'll bet the criteria for accuracy is different.

Not at the point where the data is transmitted vis Firewire.
The transfer from tape to computer file is bit-perfect, just
as any data file would be. And conversely from computer
back to tape.

Video has all sorts of correction for dropped data built in because it's
always had to deal with it.

That is mainly because of the practice of recording extremely
high data rates to mag tape which results, as you say, in a
higher failure rate to deal with. But at the point in the chain
where the data has been recovered from the tape and formed
into Firewire packets, it is just as bit-perfect as any other
computer file, regardless of whether the contents is moving
video, still images, audio, computer program files, seismic or
weather data, credit-card number databases, IRS tax returns,
or any other kind of data.

And also, we can accept a little glitch in video easier than we can accept
a little glitch in audio

Because video is regular, repetitive, and somewhat predictable.
But you can say exactly the same for audio. And that is why
(for example) Red-Book CDs can get away with lower-quality
error detection and correction than the same technology when
used with bit-perfect computer data. It is easy enough to
extrapolate lost audio information at the very liesurly pace of
even 192K sampled audio compared to the speeds that even
old junker computers operate.

Maybe Dan Lavry is right (but I can't quote you his argument against
it).

Can you at least make a reference to it?

I have only a fuzzy recollection of a chat we had at last year's AES show.
I asked him if he had a Firewire interface planned and he went off on how
Firewire can't provide accurate enough timing for multitrack audio.

Could it be that he was thinking about latency for monitoring, etc?
Because otherwise it makes him look like an idiot.

The Lynx guys DO have a Firewire option for their multi-channel converters
but they told me that they built it because the customers asked for it and
they managed to do a decent job. But that their AES/EBU setup that goes to
a PCI card is superior.

So what Lavry is saying is the equivalent of saying that digital
transmission of (for example) color television is impossible
because of variations in sample timing of red, green, and blue
pixels of any given frame. It is just absurd on its face. There is
no other way of saying it.

Whether Lavry was trying to blow you off with BS, or whether
he really has such a poor understanding of the technology, my
opinion of him is significantly diminished.

[[email protected]]

On Sep 12, 8:21 pm, Mike Rivers wrote:

But I already have a Mackie HDR24/96. Why switch to a system that
requires me to carry a computer (at minimum, two pieces - a laptop
computer and power supply) and three rack-mount interface boxes, plus
cables, plus software and the decisions that go along with that?

I had virtually no learning curve when I started using the Mackie. Of
course there was more to learn than arming the tracks and pushing the
Record button, but you could make recordings knowing only that much. No
system to assemble, no software to choose, load, register, and unlock
(and learn). I've not run across a DAW editor that's as intuitive and
easy to use as the Mackie, and it didn't take very long to learn how to
use that. Sure, I can make dozens of different kinds of edits in Sequoia
or Wavelab, but 98% of the time a simple edit with the default crossfade
time works just fine. And I can tweak the Mackie edits shouid I need to.
I don't have plug-in processing available on every track, true, but then
I didn't work that way when I used tape, and I still have my hardware
compressors, EQs, and reverbs. And I have people I can send clients to
if their projects require a full-out DAW treatment. I get bored working
on that sort of project anyway.

Mike how do you get the audio out of your mackie??
do you move the HD, or do the eithernet, or the real time??
and how do you you like the a/d convertors in the i/o cards??

[Mike Rivers]

Richard Crowley wrote:
Video has all sorts of correction for dropped data built in because it's
always had to deal with it.

That is mainly because of the practice of recording extremely
high data rates to mag tape which results, as you say, in a
higher failure rate to deal with. But at the point in the chain
where the data has been recovered from the tape and formed
into Firewire packets, it is just as bit-perfect as any other
computer file, regardless of whether the contents is moving
video, still images, audio, computer program files, seismic or
weather data, credit-card number databases, IRS tax returns,
or any other kind of data.

So there's some kind of buffering going on getting from the tape to the
Firewire port to take care of errors read from the tape? This is no
longer real time, and the Firewire transfer can go on at its own pace.
But we're not talking about video here, nor particularly about real time
multi-channel audio transfer. We're talking about hardware/driver
interoperability that the ability to predict it from limited product
data. Of course all we should need to know is "Firewire" but experience
has shown that, because not every maker interprets the standard in the
same way, or choose to ignore or modify certain parameters of the
standard (or maybe it's just not well enough specified) there's some
trial-and-failure involved.

And also, we can accept a little glitch in video easier than we can accept
a little glitch in audio

Because video is regular, repetitive, and somewhat predictable.
But you can say exactly the same for audio.

You can't to some DAW users who look at the waveform and see
out-of-place samples, or hear clicks because there are enough of them
together to be audible.

(for example) Red-Book CDs can get away with lower-quality
error detection and correction than the same technology when
used with bit-perfect computer data.

When the error correction has to work too hard, it's audible. It may not
be objectionable to most users, and that's why CDs have been as
successful as they are. But the fact is that there are errors. Some are
corrected completely because there's enough data to reconstruct the
missing parts. Some are interpolated. The system is smart enough to know
when to give up and mutes, which is clearly detectable. As you say,
there's usually plenty of time for the magic to work, but sometimes the
magic simply isn't powerful enough. In CD playback you can, in reality,
allow as much time as is necessary, but it must be consistent and constant.


Maybe Dan Lavry is right (but I can't quote you his argument against
it).

Could it be that he was thinking about latency for monitoring, etc?
Because otherwise it makes him look like an idiot.

It could very well be about monitoring. That's pretty important in
studio applications, not just for tracking, but for mixing as well. If
you can't hear right, you can't mix right.

So what Lavry is saying is the equivalent of saying that digital
transmission of (for example) color television is impossible
because of variations in sample timing of red, green, and blue
pixels of any given frame. It is just absurd on its face. There is
no other way of saying it.

Don't put words into his mouth. Ask him about Firewire and see what he
has to say. He'll give you the answer as you see it, but I'll warn you
that he doesn't take well to contradictions without good technical and
relevant backup. His background is in digital processing. Don't judge
his beliefs based on my fuzzy recollection. All I can tell you for sure
is that he doesn't believe that he can make a Firewire audio interface
that's as good as his AES/EBU interfaces, so he won't. He had similar
feelings about 192 kHz sample rate hardware, too. It's not that he
doesn't make it because he doesn't believe it's necessary, he doesn't
make it because he can't find components that support any better
performance than at 96 kHz. Nor does he believe that anyone else does.
If he thought that Apogee or Presonus or M-Audio was stealing his
business because they were making better converters than his, he'd
figure out how they were doing it.

I really don't feel comfortable defending someone who I don't fully
understand. If you think you do, feel free to take him on. Or just don't
buy a Lavry converter out of spite.


--
If you e-mail me and it bounces, use your secret decoder ring and reach
me he
double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers
)

[Mike Rivers]

Scott Dorsey wrote:

That used to be a standard thing.... folks built their own custom gear
to suit how they worked in the studio.

I don't understand why folks aren't doing it today with software, especially
as software is a lot easier to change.

In one sense you can say that they are, by adding software plug-ins to
their DAW mixer. But there aren't equivalent software tools to an
oscilloscope and distortion analyzer to help get the pieces working
together.



--
If you e-mail me and it bounces, use your secret decoder ring and reach
me he
double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers
)

[Mike Rivers]

wrote:

Mike how do you get the audio out of your mackie??
do you move the HD, or do the eithernet, or the real time??

Real time, analog to the console.

and how do you you like the a/d convertors in the i/o cards??

No complaints. While there may not be much value to comparing one Mackie
product to another, here's an experiment I've used to demonstrate to
myself that I don't need to run out and buy new converters. I connected
a mic to a Mackie 800R, and connected the analog, AES/EBU, and ADAT
optical outputs to separate channels of Mackie recorder. I played them
back through the Mackie's D/A converters, and heard very slight
differences between them. To eliminate differences between channels in
the console, I moved all of the samples to a single track and played
them back sequentially rather than being able to A/B/C them. No
perceptible difference. So at least the Mackie HDR's A/D converters are
compraable to those in the several years new 800R.

In other words, I'm satisfied with what I have. The only problem is that
when tracking vocals, the delay through the recorder is enough to cause
comb filtering in the singer's ear if the headphone level isn't very
loud. I can fix this by sending his vocal to the phones from the console
(analog) input rather than the recorder output.


--
If you e-mail me and it bounces, use your secret decoder ring and reach
me he
double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers
)

[[email protected]]

On Sep 13, 10:01 am, Mike Rivers wrote:
wrote:
Mike how do you get the audio out of your mackie??
do you move the HD, or do the eithernet, or the real time??

Real time, analog to the console.
so you do not use the digital files in a daw?
you use this as a digital recorder in replacement to your analogue
recorder
in your analogue based studio?

and how do you you like the a/d convertors in the i/o cards??

No complaints. ...
In other words, I'm satisfied with what I have.

so all your "rants" about firewire are academic?

[Richard Crowley]

"Mike Rivers" wrote ...

So there's some kind of buffering going on getting from the tape to the
Firewire port to take care of errors read from the tape?

Exactly as there is with DAT, or any other kind of digital audio
recording.

This is no longer real time, and the Firewire transfer can go on at its
own pace.

Not at all. The video frames come 30 every second (or 25 in the
PAL territories). What would you propose doing with the extra
frames if you are lolling around going "at its own pace"? :-)
Video is as "real-time" as it gets. Or then by your method, DAT
isn't "real-time". Is that what you are saying?

But we're not talking about video here, nor particularly about real time
multi-channel audio transfer. We're talking about hardware/driver
interoperability that the ability to predict it from limited product data.
Of course all we should need to know is "Firewire" but experience has
shown that, because not every maker interprets the standard in the same
way, or choose to ignore or modify certain parameters of the standard (or
maybe it's just not well enough specified) there's some trial-and-failure
involved.

And also, we can accept a little glitch in video easier than we can
accept a little glitch in audio

Because video is regular, repetitive, and somewhat predictable.
But you can say exactly the same for audio.

You can't to some DAW users who look at the waveform and see out-of-place
samples, or hear clicks because there are enough of them together to be
audible.

I don't think we're talking about the same thing here.

(for example) Red-Book CDs can get away with lower-quality
error detection and correction than the same technology when
used with bit-perfect computer data.

When the error correction has to work too hard, it's audible. It may not
be objectionable to most users, and that's why CDs have been as successful
as they are. But the fact is that there are errors. Some are corrected
completely because there's enough data to reconstruct the missing parts.
Some are interpolated. The system is smart enough to know when to give up
and mutes, which is clearly detectable. As you say, there's usually plenty
of time for the magic to work, but sometimes the magic simply isn't
powerful enough. In CD playback you can, in reality, allow as much time as
is necessary, but it must be consistent and constant.

No, you really can't "allow as much time as is necessary" or, as you say,
you will hear gaps in the playback. If you can't accomplish the task in
real-time, you must give up and mute. To mis-quote the old radio DJ
phrase: "the bits just keep coming!". Same in digital video.

I really don't feel comfortable defending someone who I don't fully
understand. If you think you do, feel free to take him on. Or just don't
buy a Lavry converter out of spite.

Lavry wouldn't be the first genius in one area spouting mis-information
about some other area he is clueless about.

[Scott Dorsey]

In article HSMyk.54$8v5.8@trnddc01, Mike Rivers wrote:
Scott Dorsey wrote:

That used to be a standard thing.... folks built their own custom gear
to suit how they worked in the studio.

I don't understand why folks aren't doing it today with software, especially
as software is a lot easier to change.

In one sense you can say that they are, by adding software plug-ins to
their DAW mixer.

Yes, but you don't find a lot of studios with their own custom plug-ins.
I mean, there are a few out there... and back when digital was new you
did see some studios with homebrew DAW software... but it's not common.

But there aren't equivalent software tools to an
oscilloscope and distortion analyzer to help get the pieces working
together.

Well, you DO have a scope and a distortion analyzer plug-in... and you
also have a multi-process debugger. It's the stuff in-between that can
get a little hard.
--scott


--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Mike Rivers]

wrote:

so you do not use the digital files in a daw?
you use this as a digital recorder in replacement to your analogue
recorder in your analogue based studio?

If you want to look at it that way, yes. Actually, I use the Mackie
recorder as a recorder in my studio, and use a DAW to edit. I have
fooled around with mixing on the computer, but have never actually done
a real project that way.

so all your "rants" about firewire are academic?

No. My rants about the lack of usable documentation for the system
engineer just happen to employ Firewire as an example.



--
If you e-mail me and it bounces, use your secret decoder ring and reach
me he
double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers
)

[Mike Rivers]

Richard Crowley wrote:

The video frames come 30 every second (or 25 in the
PAL territories). What would you propose doing with the extra
frames if you are lolling around going "at its own pace"? :-)
Video is as "real-time" as it gets. Or then by your method, DAT
isn't "real-time". Is that what you are saying?

You're watching video over Firewire? Why in the world would you do that?
I thought you were transferring digital data from the camera to the
computer. That can be done at any pace, ideally faster than real time,
but slower doesn't matter because you aren't going to watch the video
again until the data is on the computer. Presumably everything has
sufficient timing information so that it will play properly off the
computer's disk.

Why are we talking about video anyway? We were talking about
documentation of Firewire components and why they can be mismatched in
ways that keep them from transferring real time audio data properly.

I don't think we're talking about the same thing here.

I don't know why we're discussing video at all. I don't know diddly
about it so you can argue all you want. You're talking to a virtual
idiot so you can't win.

Lavry wouldn't be the first genius in one area spouting mis-information
about some other area he is clueless about.

Why do you think he's clueless when you don't even know what he said?
Like I said, ask him about Firewire. Don't ask me what he said about it.
All I can tell you is that he doesn't think it works well enough for him
to put his name on.



--
If you e-mail me and it bounces, use your secret decoder ring and reach
me he
double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers
)

[Scott Dorsey]

Mike Rivers wrote:
Richard Crowley wrote:

The video frames come 30 every second (or 25 in the
PAL territories). What would you propose doing with the extra
frames if you are lolling around going "at its own pace"? :-)
Video is as "real-time" as it gets. Or then by your method, DAT
isn't "real-time". Is that what you are saying?

You're watching video over Firewire? Why in the world would you do that?

Because that is what Firewire is for. Firewire has stuff built into it
to permit realtime data transfer.

I thought you were transferring digital data from the camera to the
computer. That can be done at any pace, ideally faster than real time,
but slower doesn't matter because you aren't going to watch the video
again until the data is on the computer. Presumably everything has
sufficient timing information so that it will play properly off the
computer's disk.

Right. You can do this with USB or firewire, SCSI or even RS-232 if you
are willing to wait long enough.

The advantage of Firewire, as a lot of folks have been saying in this
thread, is that it has stuff built into the interface to allow realtime
data transfer.

Why are we talking about video anyway? We were talking about
documentation of Firewire components and why they can be mismatched in
ways that keep them from transferring real time audio data properly.

Realtime is realtime. You can throw bandwidth at a problem and it might
work in realtime most of the time, but that doesn't make it a realtime
system because deadlines are not guaranteed. Firewire allows deadlines
to be guaranteed.

I don't know why we're discussing video at all. I don't know diddly
about it so you can argue all you want. You're talking to a virtual
idiot so you can't win.

Data is data. It doesn't matter if it's audio, video, or radar, it's
all just bits. A realtime interface guarantees the bits will be in the
right place at the right time. A non-realtime interface does not.

Lavry wouldn't be the first genius in one area spouting mis-information
about some other area he is clueless about.

Why do you think he's clueless when you don't even know what he said?
Like I said, ask him about Firewire. Don't ask me what he said about it.
All I can tell you is that he doesn't think it works well enough for him
to put his name on.

Lavry's issues have mostly to do with some lousy firewire implementations
on Windows systems, and not with firewire itself. Still, he has to support
what he sells, and he probably doesn't want to spend a lot of time explaining
to people that his system isn't the problem.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[[email protected]]

On Sep 13, 2:40 pm, (Scott Dorsey) wrote:

Lavry's issues have mostly to do with some lousy firewire implementations
on Windows systems, and not with firewire itself. Still, he has to support
what he sells, and he probably doesn't want to spend a lot of time explaining
to people that his system isn't the problem.

isn't this where I came in

there are issues with firewire and windows machines. the quality/type of firewire card/port in your window's machine can make a difference!

[[email protected]]

On Sep 13, 2:40 pm, (Scott Dorsey) wrote:

Lavry's issues have mostly to do with some lousy firewire implementations
on Windows systems, and not with firewire itself. Still, he has to support
what he sells, and he probably doesn't want to spend a lot of time explaining
to people that his system isn't the problem.

isn't this where I came in

there are issues with firewire and windows machines. the quality/type of firewire card/port in your window's machine can make a difference!

[Mike Rivers]

Scott Dorsey wrote:

The advantage of Firewire, as a lot of folks have been saying in this
thread, is that it has stuff built into the interface to allow realtime
data transfer.

Fine, as long as it works. But it doesn't always work between two
randomly selected devices with a Firewire port.

Realtime is realtime. You can throw bandwidth at a problem and it might
work in realtime most of the time, but that doesn't make it a realtime
system because deadlines are not guaranteed. Firewire allows deadlines
to be guaranteed.

I wouldn't expect a guarantee, but I would expect that if you know the
maximum official transfer rate and you don't exceed 50% of that, and you
don't have a terribly busy computer, it will get the data there when
it's needed. I'm not talking about that problem. I'm talking about the
data either not getting there at all or getting there sporadically so
there are gaps or pops. This happens sometimes with some systems and
never with others.

There should be a way to predict on which systems it will always work
correctly but I haven't seen anything other than "Use a TI chipset" and
I don't believe that's the solution. If it was then either other chip
manufacturers would figure out what TI was doing differently and do it
themselves. Or they'd just go out of the Firewire business. Why tolerate
things that we know don't work. The trouble is that we don't know
accurately what doesn't work.

I'm not complaining that Firewire can't hand audio. I'm complaining that
we who attempt to put together audio systems can't reliably handle
Firewire.

Lavry's issues have mostly to do with some lousy firewire implementations
on Windows systems, and not with firewire itself. Still, he has to support
what he sells, and he probably doesn't want to spend a lot of time explaining
to people that his system isn't the problem.

I expect that this is my problem as well. Nobody knows why there are
issues with Windows (though I've heard of some with Mac OS as well) or
if they know, they don't have the tools to fix it. And since pro audio
is such a small part of the business, Microsoft doesn't put a lot of
time into fixing problems with Firewire. In one version of Windows, they
"fixed" a Firewire problem by slowing down the maximum rate from 400 to
100 mbps. That put a bunch of users who had working systems out of
business until word got around as to how to un-fix that fix.



--
If you e-mail me and it bounces, use your secret decoder ring and reach
me he
double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers
)

[Scott Dorsey]

Mike Rivers wrote:
Scott Dorsey wrote:

The advantage of Firewire, as a lot of folks have been saying in this
thread, is that it has stuff built into the interface to allow realtime
data transfer.

Fine, as long as it works. But it doesn't always work between two
randomly selected devices with a Firewire port.

It does, as long as one of them isn't a Windows machine with a flaky
Firewire implementation that does not meet the specs.

Damning Firewire for this reason is like damning S-PDIF because Panasonic
refused to implement it properly.

Realtime is realtime. You can throw bandwidth at a problem and it might
work in realtime most of the time, but that doesn't make it a realtime
system because deadlines are not guaranteed. Firewire allows deadlines
to be guaranteed.

I wouldn't expect a guarantee, but I would expect that if you know the
maximum official transfer rate and you don't exceed 50% of that, and you
don't have a terribly busy computer, it will get the data there when
it's needed. I'm not talking about that problem. I'm talking about the
data either not getting there at all or getting there sporadically so
there are gaps or pops. This happens sometimes with some systems and
never with others.

No, you get a guarantee with Firewire, just like you do with a synchronous
serial interface like S-PDIF or MADI. It's intended for that. If you
get clicks or pops, it's because something is wrong with one of the
interfaces.

There should be a way to predict on which systems it will always work
correctly but I haven't seen anything other than "Use a TI chipset" and
I don't believe that's the solution. If it was then either other chip
manufacturers would figure out what TI was doing differently and do it
themselves. Or they'd just go out of the Firewire business. Why tolerate
things that we know don't work. The trouble is that we don't know
accurately what doesn't work.

Because there will ALWAYS be incompetently-designed interfaces that do not
meet the published specifications, no matter what interface you use. If
Panasonic isn't responsible for it, somebody else will be.

Part of the reason why nobody really knows what is wrong with the Windows
drivers is that nobody can look inside them. Welcome to the wonderful world
of proprietary Microsoft systems.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Mike Rivers]

On Sep 13, 4:22 pm, (Scott Dorsey) wrote:

Fine, as long as it works. But it doesn't always work between two
randomly selected devices with a Firewire port.

It does, as long as one of them isn't a Windows machine with a flaky
Firewire implementation that does not meet the specs.

If it's a Windows problem, why do some people recommend (or recommend
against) certain Firewire chips. Since TI seems to be most
consistently recommended, does that suggest that TI is the only one
who understands how Windows uses Firewire and accommodates it? And why
do I have a VIA and an NEC chipset that works with all of my
equipment, yet some people say that VIA doesn't work with their
equipment? Or even if they have the same combination as I do, mine
works and theirs doesn't?

I can accept that it's a Windows problem, a chipset problem (in either
the host or the audio device) or a driver problem. But we shouldn't
have to guess. Nor should we have to rely on anecdotal experience. We
should be able to read the documentation and figure it out. I know
that I can't do that.

No, you get a guarantee with Firewire, just like you do with a synchronous
serial interface like S-PDIF or MADI. It's intended for that. If you
get clicks or pops, it's because something is wrong with one of the
interfaces.

My point exactly. So how can you tell from the available data which
interfaces have something wrong with them? Factor in the fact that
even if there's something wrong, it might still work. Fortunately it
works more often than it doesn't, for whatever reasons. Maybe more
companies are doing it right and it's now an old wives' tale that
certain Firewire chips don't work, or don't work in certain computers,
or with certain audio hardware. I don't keep up.

[[email protected]]

On Sep 13, 5:34 pm, Mike Rivers wrote:
On Sep 13, 4:22 pm, (Scott Dorsey) wrote:

Fine, as long as it works. But it doesn't always work between two
randomly selected devices with a Firewire port.

It does, as long as one of them isn't a Windows machine with a flaky
Firewire implementation that does not meet the specs.

If it's a Windows problem, why do some people recommend (or recommend
against) certain Firewire chips. Since TI seems to be most
consistently recommended, does that suggest that TI is the only one
who understands how Windows uses Firewire and accommodates it? And why
do I have a VIA and an NEC chipset that works with all of my
equipment, yet some people say that VIA doesn't work with their
equipment? Or even if they have the same combination as I do, mine
works and theirs doesn't?

I can accept that it's a Windows problem, a chipset problem (in either
the host or the audio device) or a driver problem. But we shouldn't
have to guess. Nor should we have to rely on anecdotal experience. We
should be able to read the documentation and figure it out. I know
that I can't do that.

No, you get a guarantee with Firewire, just like you do with a synchronous
serial interface like S-PDIF or MADI. It's intended for that. If you
get clicks or pops, it's because something is wrong with one of the
interfaces.

My point exactly. So how can you tell from the available data which
interfaces have something wrong with them? Factor in the fact that
even if there's something wrong, it might still work. Fortunately it
works more often than it doesn't, for whatever reasons. Maybe more
companies are doing it right and it's now an old wives' tale that
certain Firewire chips don't work, or don't work in certain computers,
or with certain audio hardware. I don't keep up.

Mike
we don't have to guess. I can accept that you think I have been
feeding you some BS tripe, but when Dan Lavery and Scott have told you
that it is a _Window's_ problem.
do you think they are lying to you???
what ****ed on rope have you been smoking???

[Mike Rivers]

wrote:

we don't have to guess. I can accept that you think I have been
feeding you some BS tripe, but when Dan Lavery and Scott have told you
that it is a _Window's_ problem.
do you think they are lying to you???
what ****ed on rope have you been smoking???

I don't think anyone's been feeding me BS. It's just that my question
hasn't been answered - HOW CAN YOU TELL THAT A CERTAIN COMBINATION OF
FIREWIRE DEVICES WON'T WORK UNLESS YOU TRY THEM???? I can tell you that
a microphone won't work properly when connected to a line level input,
and I can tell you HOW it won't work improperly. Why can't you tell me
that a MOTU interface will click when connected to a Firewire host card
with a VIA chipset? (just a made-up example)

Or can we just assume that no Firewire system will work with Windows and
be done with it?




--
If you e-mail me and it bounces, use your secret decoder ring and reach
me he
double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers
)

[[email protected]]

On Sep 13, 6:20 pm, Mike Rivers wrote:

I don't think anyone's been feeding me BS. It's just that my question
hasn't been answered - HOW CAN YOU TELL THAT A CERTAIN COMBINATION OF
FIREWIRE DEVICES WON'T WORK UNLESS YOU TRY THEM???? I can tell you that
a microphone won't work properly when connected to a line level input,
and I can tell you HOW it won't work improperly. Why can't you tell me
that a MOTU interface will click when connected to a Firewire host card
with a VIA chipset? (just a made-up example)

Or can we just assume that no Firewire system will work with Windows and
be done with it?

Mike
because all the specs are always changing because someone decides that
they need to redesign (that is their job security) for a price point
or has a new cheaper asian OEM come on line so that they can sell
their product at a required price or the need for an interface at the
less then $$$ price point.
you have to try them or find someone who has!!!

[Mike Rivers]

wrote:

because all the specs are always changing because someone decides that
they need to redesign (that is their job security) for a price point
or has a new cheaper asian OEM come on line so that they can sell
their product at a required price or the need for an interface at the
less then $$$ price point.
you have to try them or find someone who has!!!

Thank you for supporting my point. As to the "someone who has," who do
you trust? And who has exactly the same system that the one asking "will
it work?" has? If the standard really worked, everything would work with
everything else. Because it doesn't, either the standard is allowing
deviations that don't work under certain conditions or the manufacturers
are knowingly or not deviating from the standard.

Either way, there's no sure bet. The good news is that it seems that
there are fewer combinations that don't work, but sooner or later
someone's going to buy one and we'll hear about it here.


--
If you e-mail me and it bounces, use your secret decoder ring and reach
me he
double-m-eleven-double-zero at yahoo -- I'm really Mike Rivers
)

[Richard Crowley]

"Mike Rivers" wrote ...
You're watching video over Firewire? Why in the world would you do that?

Mr. Dorsey has responded to your questions. I have nothing further to add.

Why do you think he's clueless when you don't even know what he said? Like
I said, ask him about Firewire. Don't ask me what he said about it. All I
can tell you is that he doesn't think it works well enough for him to put
his name on.

If he is saying that various unknwon Windows implementations of Firewire
aren't reliable enough for him, I can accept that. As a very small company,
he doesn't have the resources to deal with the thousands of different
variations his customers might encounter. That is what is nice about the
Mac world. You are dealing with a closed, proprietary world and you
have only one hardware vendor (Apple) and one sofware vendor (Apple
again) to deal with.

But that gobbeldygook about samples going out of phase is just stupid.
It might be better to not quote him at all if we don't know exactly what
he said.

[Richard Crowley]

"Scott Dorsey" wrote ...
Lavry's issues have mostly to do with some lousy firewire implementations
on Windows systems, and not with firewire itself. Still, he has to
support
what he sells, and he probably doesn't want to spend a lot of time
explaining
to people that his system isn't the problem.

Although it makes you wonder how scores of manufacturers of
camcorders (many of which cost less than Lavry's cheapest converter
box) seem to be able to use Firewire for real-time video without any
of these problems. Things that make you go, hmmmm.

[[email protected]]

On Sep 13, 7:10 pm, Mike Rivers wrote:

Thank you for supporting my point. As to the "someone who has," who do
you trust? And who has exactly the same system that the one asking "will
it work?" has? If the standard really worked, everything would work with
everything else. Because it doesn't, either the standard is allowing
deviations that don't work under certain conditions or the manufacturers
are knowingly or not deviating from the standard.

if everyone built their components to the agreed standards then it
would work but
very few people actually are concerned with standards and more with
how cheap can I buy it. Windows is the standard operating system for
how many computer manufacturers???100, 200, 1000???
and they are competing for your want for a computer at the under
$9.95.
so they make their OS very broad so it can work with every tom dick
and jane's
store bought or home built computer.
hell you can not get the audio manufacturers to work to agreed
standards ...
so I choose to go with a computer manufacturer who builds to their own
specs and that includes their own OS. It works with most everything
with very little ****ing around. I buy a new peripheral and the
included manual has 10 pages of instructions for windows machines and
1 for mine. usually plug it in!! It works!!! Plextor to Presonus. Sony
iLink to Yamaha mLan. yeah I paid more for it but ... no chasing
around trying this and that.
You get what you pay for. If you save a buck on that pc ,you sure
have to work many hours to get it to do the job. what do you charge
for an hour of your time???

[Laurence Payne[_2_]]

On Sat, 13 Sep 2008 17:15:48 GMT, Mike Rivers
wrote:

You're watching video over Firewire? Why in the world would you do that?
I thought you were transferring digital data from the camera to the
computer. That can be done at any pace, ideally faster than real time,
but slower doesn't matter because you aren't going to watch the video
again until the data is on the computer. Presumably everything has
sufficient timing information so that it will play properly off the
computer's disk.

The video camera is streaming data in real time. You can therefore
monitor it if you choose to.



Why are we talking about video anyway?

Because you incorrectly used it as an example of how Firewire isn't
designed for real-time transfer, while in fact it's an example of how
it IS :-)

[Lucky[_3_]]

Scott Dorsey wrote:

You're watching video over Firewire? Why in the world would you do that?

Because that is what Firewire is for. Firewire has stuff built into it
to permit realtime data transfer.

I do it all the time. I'd never bother with USB.

[Lucky[_3_]]

Mike Rivers wrote:

I'm not complaining that Firewire can't hand audio. I'm complaining that
we who attempt to put together audio systems can't reliably handle
Firewire.

Then don't. The rest of of are doing fine without even thinking about it.

[Lucky[_3_]]

Geez, Mike.

Just get a Mac, or shut the **** up about your frustrations with
re-inventing the wheel. You're too old for this.

[Lucky[_3_]]

Richard Crowley wrote:

Although it makes you wonder how scores of manufacturers of
camcorders (many of which cost less than Lavry's cheapest converter
box) seem to be able to use Firewire for real-time video without any
of these problems. Things that make you go, hmmmm.

I use a Canon camcorder for that purpose. It works just fine.