Preliminary Review of Traveler MKIII
Posted: Sat Jan 17, 2009 8:55 pm
I wrote this for the usenet group rec.audio.opinion. The product description is probably obvious to everyone here, but the second half of the article has some observations about the driver that you may find interesting.
Review:
The physical quality is impressive, with a completely aluminum outer shell and functional rounded edges. The first thing I always do with a new piece of equipment is a drop-test
In this case, the Traveler was perched on a cardboard box that turned out to be unstable. It sustained a three-foot fall to a carpeted floor, causing a knob to fall off, and slightly bend a shaft. I straightened the shaft with a wrench, and glued the knob back on. The Traveler survived with no functional impairment because the rotary encoders are secured to a metal plate behind the panel, and the shafts themselves are snap-in. The Traveler uses rotary encoders, not analog pots, which in theory have an indefinite lifetime. The panels are screwed down with Torx fasteners. In a word, this is not consumer quality construction; it's professional quality. It has a locking 4 pin Arri power connector, and it syncs to SMPTE time code, which means it can go right to work on a movie set.
The new MKIII has a direct-digital-synthesis clock, which interested me, because there is good evidence that the original Traveler did not perform up to the potential of the converters. The reviewers liked the sound of the original Traveler, but with the subsequent qualifications of users who more accurately assigned a level of quality of "good", rather than "excellent", the original reviews are just another indication of the severely flawed reviews typical of professional and semiprofessional equipment. Since I do not have the opportunity to make multiple recordings with the same musicians and conditions, it would be difficult for me to report with authority how it sounds in comparison with other equipment. My hope is that, with the considerable revamp of the internals, new A/D, new pres, it may not be an issue, as it apparently was with the original Traveler. The advertising of state-of-the-art clock synthesis is a very, very promising indication that the intent may be to compete with Apogee.
The Traveler has features popular with the amateur musician, such as reverb, that I will never use. My interest is as a relatively cheap, lightweight, location recorder. It can be powered via Firewire bus, AC adapter, or 10-24VDC battery, "three ways from Sunday", if not six, and is even protected against reverse polarity.
The most vocal complaints about the Traveler have been about the driver. I have now installed the Traveler to two Windows XP laptops, and I have a pretty good idea where the problems lie. I have also compared the performance of the Traveler driver to that of the Echo AudioFire 12, with some interesting results.
Laptop #1: Compal CL50, a 15" second generation Centrino notebook circa 2003, with a CPU upgraded to a Centrino 765, a 2.1 GHz chip with 2 megs of cache. The laptop chipset is the 855PM, with Radeon 9000 discrete graphics. RAM is 2 gigabytes. Hard disk: Western Digital BEVE250, 250GB.
Laptop #2: Asus S5NE, a 2.75 lb subnotebook, first generation Centrino, circa 2004, with a 1 GHz/1meg cache ultra-low-voltage CPU, an 855GM chipset which uses the CPU to run the screen. RAM=1.25GB. The hard disk is identical to laptop #1.
Because Laptop #2 does not have a discrete graphics card, and because the CPU is not only slower but has less cache, laptop #1 is about 3X faster than laptop #2.
The Traveler installed without incident to the Compal, using the built-in Via Firewire chipset. However, the driver exhibited unusual behavior. Immediately upon turn-on of the Traveler, CPU usage went to 40% and remained at that level for about a minute. CPU usage also spiked when the Traveler was turned off. This happened without a DAW program running. The process table indicated that the CPU usage was happening in the kernel itself, in other words, in the Traveler driver, or caused by that driver. When the Traveler was turned off, it took an unusually long time for the event to be recognized.
A Steinberg Cubase Studio 4.52 project was created with 8 tracks. One hour of recording was accomplished without glitches. CPU usage settled down to about 30%. I then forced the CPU speed to remain at 600MHz and repeated the experiment. Although CPU usage went up, the machine acquired for one hour and remained responsive.
MOTU does not damn the Via Firewire chipset, but they recommend TI. In the next experiment, the built-in port was replaced by a TI based Cardbus adapter, even though (important!) the Cardbus slot in this laptop is known to have a problem: it does not give a Firewire card an exclusive interrupt. This causes problems with most, but not all, audio drivers. A Tascam FW-1082 works in this configuration. An Echo AudioFire 12 exhibits diginoise, but the system does not crash.
A Traveler crashes. Badly. It bluescreens, does a ram dump, and on reboot, the OS telegraphs Microsoft with the message that a serious error has occurred. A kernel crash is the most serious software-only error that can occur. The crash was caused by a specific hardware deficiency, but strangely, MOTU does not address this in their tech notes. And the way it crashes does not offer suggestion to the user.
The installation was repeated on the Asus laptop. With respect to the outcome, bear in mind that, in terms of ability, the closest comparable modern machine is an Atom based netbook. This is a slow machine, and few would desire to use it for DAW work. But I have, and I do, and I wanted to continue with the Traveler if it were possible.
When the Traveler is connected, CPU usage goes to 100%. After a few minutes of doing nothing, it declines to around 20%. However, when Steinberg Cubase is running, CPU usage goes to 100% and stays there. The cursor will not follow the mouse pointer. The combination of Traveler and Cubase is not usable. Increasing the buffer size to maximum, and disabling the optical connections, made no difference.
Since a TI Firewire interface was recommended, I inserted the Cardbus card and tried again. Since on the Asus, the Cardbus card does not share an interrupt, there was no crash. But the problem remained: 100% CPU usage. Mathematically, this is perfectly expected, since the Asus is 1/3 the speed of the Compal.
I have had good luck with the AudioFire 12 in the past. Now I wanted to check it. I set it up for 12-channel recording with the Asus. Running at full tilt, recording 12 channels, CPU usage was about 30%!
The Traveler and the AudioFire have distinctly different feature sets. The Traveler has 8 analog inputs and a lot of digital connectivity, an internal digital crossbar and mixer, and reverb. The AudioFire has 12 analog inputs, 12 analog outputs, an internal digital crossbar switch/mixer, and no digital connectivity. Nevertheless, I do not see anything in the Traveler feature set that justifies taking 100% of any CPU. I think I know the name of the dirty culprit, and his name is:
"Spin lock." This guy is the only method a driver has to reserve resources for it's own use, and he's tricky. A spin lock can be held for no more than 35 microseconds, or the equivalent of a freeway pileup occurs in the kernel. When the kernel sees too many cars on the road, i.e., drivers waiting their turn, it infers a crash -- blue screen. The Traveler driver uses too many spin locks, because it's easier than multithreading.
There are things that catch a programmer's eye. Size of a driver, for example. The MOTU driver package is 24 megabytes. The size of the AudioFire package is 1.5 megabytes. The MOTU package is SIXTEEN times larger, yet, as far as I can tell, both do essentially the same thing. This is called "code bloat", and there are a number of reasons for it:
1. Big libraries linked in that contain extraneous code.
2. A universal driver is fitted with a "wrapper", so that it can be used on both Mac and Windows.
3. Inefficient development environment.
4. Skill. Some programmers are coding geniuses. Some are just very competent. There are no dumb guys in this business.
5. Money. The more perfect the driver, the more it costs.
I would not be too hard on MOTU for not having the best driver team in the business. In the right machine, it's solid. Their hardware requirements seem a bit optimistic, as I see no way a 1 GHz machine could work with the Traveler without severe impairment. The MOTU driver is not aware of what it needs to work. Put it in a hardware environment that omits a requirement, and it will simply blue screen, leading to the considerable numbers of unhappy MOTU owners, alongside those who, having the "right" environment, are happy.
The question I cannot answer is whether this MKIII will continue to work. This is a real concern, considering the complaints about late-manufacture original Travelers. The external ruggedness is real, not cosmetic. At the same time, the ticking time bomb of bad ROHS soldering in some Chinese factory cannot be ruled out. I'll use it, hoping the lightning misses me.
Hope you found this useful,
Bob Morein
(310) 237-6511
Review:
The physical quality is impressive, with a completely aluminum outer shell and functional rounded edges. The first thing I always do with a new piece of equipment is a drop-test
In this case, the Traveler was perched on a cardboard box that turned out to be unstable. It sustained a three-foot fall to a carpeted floor, causing a knob to fall off, and slightly bend a shaft. I straightened the shaft with a wrench, and glued the knob back on. The Traveler survived with no functional impairment because the rotary encoders are secured to a metal plate behind the panel, and the shafts themselves are snap-in. The Traveler uses rotary encoders, not analog pots, which in theory have an indefinite lifetime. The panels are screwed down with Torx fasteners. In a word, this is not consumer quality construction; it's professional quality. It has a locking 4 pin Arri power connector, and it syncs to SMPTE time code, which means it can go right to work on a movie set. The new MKIII has a direct-digital-synthesis clock, which interested me, because there is good evidence that the original Traveler did not perform up to the potential of the converters. The reviewers liked the sound of the original Traveler, but with the subsequent qualifications of users who more accurately assigned a level of quality of "good", rather than "excellent", the original reviews are just another indication of the severely flawed reviews typical of professional and semiprofessional equipment. Since I do not have the opportunity to make multiple recordings with the same musicians and conditions, it would be difficult for me to report with authority how it sounds in comparison with other equipment. My hope is that, with the considerable revamp of the internals, new A/D, new pres, it may not be an issue, as it apparently was with the original Traveler. The advertising of state-of-the-art clock synthesis is a very, very promising indication that the intent may be to compete with Apogee.
The Traveler has features popular with the amateur musician, such as reverb, that I will never use. My interest is as a relatively cheap, lightweight, location recorder. It can be powered via Firewire bus, AC adapter, or 10-24VDC battery, "three ways from Sunday", if not six, and is even protected against reverse polarity.
The most vocal complaints about the Traveler have been about the driver. I have now installed the Traveler to two Windows XP laptops, and I have a pretty good idea where the problems lie. I have also compared the performance of the Traveler driver to that of the Echo AudioFire 12, with some interesting results.
Laptop #1: Compal CL50, a 15" second generation Centrino notebook circa 2003, with a CPU upgraded to a Centrino 765, a 2.1 GHz chip with 2 megs of cache. The laptop chipset is the 855PM, with Radeon 9000 discrete graphics. RAM is 2 gigabytes. Hard disk: Western Digital BEVE250, 250GB.
Laptop #2: Asus S5NE, a 2.75 lb subnotebook, first generation Centrino, circa 2004, with a 1 GHz/1meg cache ultra-low-voltage CPU, an 855GM chipset which uses the CPU to run the screen. RAM=1.25GB. The hard disk is identical to laptop #1.
Because Laptop #2 does not have a discrete graphics card, and because the CPU is not only slower but has less cache, laptop #1 is about 3X faster than laptop #2.
The Traveler installed without incident to the Compal, using the built-in Via Firewire chipset. However, the driver exhibited unusual behavior. Immediately upon turn-on of the Traveler, CPU usage went to 40% and remained at that level for about a minute. CPU usage also spiked when the Traveler was turned off. This happened without a DAW program running. The process table indicated that the CPU usage was happening in the kernel itself, in other words, in the Traveler driver, or caused by that driver. When the Traveler was turned off, it took an unusually long time for the event to be recognized.
A Steinberg Cubase Studio 4.52 project was created with 8 tracks. One hour of recording was accomplished without glitches. CPU usage settled down to about 30%. I then forced the CPU speed to remain at 600MHz and repeated the experiment. Although CPU usage went up, the machine acquired for one hour and remained responsive.
MOTU does not damn the Via Firewire chipset, but they recommend TI. In the next experiment, the built-in port was replaced by a TI based Cardbus adapter, even though (important!) the Cardbus slot in this laptop is known to have a problem: it does not give a Firewire card an exclusive interrupt. This causes problems with most, but not all, audio drivers. A Tascam FW-1082 works in this configuration. An Echo AudioFire 12 exhibits diginoise, but the system does not crash.
A Traveler crashes. Badly. It bluescreens, does a ram dump, and on reboot, the OS telegraphs Microsoft with the message that a serious error has occurred. A kernel crash is the most serious software-only error that can occur. The crash was caused by a specific hardware deficiency, but strangely, MOTU does not address this in their tech notes. And the way it crashes does not offer suggestion to the user.
The installation was repeated on the Asus laptop. With respect to the outcome, bear in mind that, in terms of ability, the closest comparable modern machine is an Atom based netbook. This is a slow machine, and few would desire to use it for DAW work. But I have, and I do, and I wanted to continue with the Traveler if it were possible.
When the Traveler is connected, CPU usage goes to 100%. After a few minutes of doing nothing, it declines to around 20%. However, when Steinberg Cubase is running, CPU usage goes to 100% and stays there. The cursor will not follow the mouse pointer. The combination of Traveler and Cubase is not usable. Increasing the buffer size to maximum, and disabling the optical connections, made no difference.
Since a TI Firewire interface was recommended, I inserted the Cardbus card and tried again. Since on the Asus, the Cardbus card does not share an interrupt, there was no crash. But the problem remained: 100% CPU usage. Mathematically, this is perfectly expected, since the Asus is 1/3 the speed of the Compal.
I have had good luck with the AudioFire 12 in the past. Now I wanted to check it. I set it up for 12-channel recording with the Asus. Running at full tilt, recording 12 channels, CPU usage was about 30%!
The Traveler and the AudioFire have distinctly different feature sets. The Traveler has 8 analog inputs and a lot of digital connectivity, an internal digital crossbar and mixer, and reverb. The AudioFire has 12 analog inputs, 12 analog outputs, an internal digital crossbar switch/mixer, and no digital connectivity. Nevertheless, I do not see anything in the Traveler feature set that justifies taking 100% of any CPU. I think I know the name of the dirty culprit, and his name is:
"Spin lock." This guy is the only method a driver has to reserve resources for it's own use, and he's tricky. A spin lock can be held for no more than 35 microseconds, or the equivalent of a freeway pileup occurs in the kernel. When the kernel sees too many cars on the road, i.e., drivers waiting their turn, it infers a crash -- blue screen. The Traveler driver uses too many spin locks, because it's easier than multithreading.
There are things that catch a programmer's eye. Size of a driver, for example. The MOTU driver package is 24 megabytes. The size of the AudioFire package is 1.5 megabytes. The MOTU package is SIXTEEN times larger, yet, as far as I can tell, both do essentially the same thing. This is called "code bloat", and there are a number of reasons for it:
1. Big libraries linked in that contain extraneous code.
2. A universal driver is fitted with a "wrapper", so that it can be used on both Mac and Windows.
3. Inefficient development environment.
4. Skill. Some programmers are coding geniuses. Some are just very competent. There are no dumb guys in this business.
5. Money. The more perfect the driver, the more it costs.
I would not be too hard on MOTU for not having the best driver team in the business. In the right machine, it's solid. Their hardware requirements seem a bit optimistic, as I see no way a 1 GHz machine could work with the Traveler without severe impairment. The MOTU driver is not aware of what it needs to work. Put it in a hardware environment that omits a requirement, and it will simply blue screen, leading to the considerable numbers of unhappy MOTU owners, alongside those who, having the "right" environment, are happy.
The question I cannot answer is whether this MKIII will continue to work. This is a real concern, considering the complaints about late-manufacture original Travelers. The external ruggedness is real, not cosmetic. At the same time, the ticking time bomb of bad ROHS soldering in some Chinese factory cannot be ruled out. I'll use it, hoping the lightning misses me.
Hope you found this useful,
Bob Morein
(310) 237-6511