Home |
Search |
Today's Posts |
#81
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
|
#82
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
|
#83
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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. |
#84
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
"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) |
#85
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
"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. |
#86
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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!!!!! |
#87
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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!!!!! |
#88
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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 ) |
#89
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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 ) |
#90
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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 ) |
#91
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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." |
#92
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
|
#93
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
"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. |
#94
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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?? |
#95
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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 ) |
#96
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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 ) |
#97
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
|
#98
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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? |
#99
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
"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. |
#100
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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." |
#101
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
|
#102
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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 ) |
#103
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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." |
#104
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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! |
#105
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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! |
#106
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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 ) |
#107
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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." |
#108
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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. |
#109
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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??? |
#110
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
|
#111
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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!!! |
#112
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
|
#113
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
"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. |
#114
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
"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. |
#115
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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??? |
#116
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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 :-) |
#117
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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. |
#118
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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. |
#119
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
Geez, Mike.
Just get a Mac, or shut the **** up about your frustrations with re-inventing the wheel. You're too old for this. |
#120
Posted to rec.audio.pro
|
|||
|
|||
Firewire vs USB2 for multichannel in?
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. |
Reply |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
Firewire/USB2/midi card for Mac G4 | Pro Audio | |||
16 channels of decent firewire or USB2 A/D converters for going into Laptop? | Pro Audio | |||
8 Channel Preamp with Firewire in AND multichannel duplexed digital return? | Pro Audio | |||
usb2 or firewire | Pro Audio | |||
Any good USB multichannel inputs? not Firewire | Pro Audio |