Preliminary review, MOTU Traveler MKIII
- From: "Soundhaspriority" <nowhere@xxxxxxxxxxx>
- Date: Sun, 18 Jan 2009 14:28:08 -0500
It occured to me that my review of the Traveler MKIII might save someone
from trying to pair it with a netbook, so here it is. I do not write for any
tech magazine, and this review is based upon a unit purchased by me from B&H
at the regular street price.
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
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 Windows
driver (Mac users should skip these remarks.) 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
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
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 including 4 mikes, 10 analog outputs, a
sophisticated digital mike limiter, a lot of digital connectivity, an
internal digital crossbar and mixer, and reverb. The AudioFire has 12 analog
inputs, 12 analog outputs, no mikes, no limiter, 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,
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.
Those who want to use the Traveler with the Mac should pay no attention to
the remarks regarding the quality of the Windows driver. It is not in any
way relevant to use with the Mac, and prospective users of the Mac should
obtain information from other sources.
Hope you found this useful,
- Re: Preliminary review, MOTU Traveler MKIII
- From: JLaFarge
- Re: Preliminary review, MOTU Traveler MKIII
- Prev by Date: Re: Warm gloves for booming
- Next by Date: Re: US RF Freqs POST changeover.
- Previous by thread: US RF Freqs POST changeover.
- Next by thread: Re: Preliminary review, MOTU Traveler MKIII