Re: Nearly OT: VF16 harddisk source
- From: Don Y <this@xxxxxxxxxxx>
- Date: Fri, 01 Jun 2012 14:27:24 -0700
Hi Mike,
On 5/31/2012 1:05 PM, Mike Rivers wrote:
On 5/31/2012 2:20 PM, Don Y wrote:
Exactly. *If* the old product(s) and the new product(s) don't
share a common implementation base -- because someone opted to
cut a corner in "old product" thereby making that aspect of
the design non-portable to the "new product".
If you're going to design products for the mass market, in order to make
them price-competitive you have to adopt someone else's technology.
Actually, that isn't true. It depends a lot on what your product
wants to be and the "commodity" components on which you can draw.
E.g., if I had opted to build my network speakers using "someone
else's technology", my *cost* would be close to $100/device.
I'd need a microcomputer/microcontroller with enough memory to
store its program (plus a big enough buffer to hold the streaming
audio data), a network interface and two D/AC's. They would
have to be connected to a two channel audio amplifier capable of
digital control (volume, etc.). And, that amplifier would have to
be very efficient to make the best use of the limited power
available from a PoE distribution system -- which would have
to be accommodated by appropriate hardware in that package, as
well.
And, that assumes I care nothing about the physical form that the
final device assumes (hint: that sort of approach wouldn't yield
the "ice cubes" that my current design fits).
OTOH, building the proof-of-principle prototypes for these devices
was easy to do with off-the-shelf components! A pair of PC's
with sound cards and network cards running software that I
spoon fed to them over the network. Too big and too expensive
but provides the same "functionality"!
This is a common misconception that folks building custom kit
get distracted by. "Let's just use a PC!" As if that, magically,
solves their problems!
I've long ago stopped arguing with these folks. Instead, I "agree"
and go through the list of what the project will entail.
- "OK, so how are we going to interface to the motors? The PC has
no concept of 'motors'..."
- "We'll buy a motor driver board".
- "How many? We have four motors to control?"
- "Four boards?"
- "So we need at least 4 slots for these four boards..."
- "No, maybe we can buy a four-motor board!"
- "OK, and how do we interface to the ultrasonic range detectors?"
- "We'll use a sound card(s)!"
- "No, doesn't have an appropriate frequency response. And, we
don't have the computational horsepower to be analyzing echoes
in real time while doing these other things"
- "OK, so we'll have to design a board to do that."
- "With a separate processor? That communicates with the processor
in the PC? How?"
Etc. When you're all done, you pick up one of the many catalogs from
board vendors and start filling in some prices.
Then, you look at the designs you *still* have to do "by yourself"
(or subcontract).
Finally, you look at how "exposed" you now are to all these
other providers. What happens if the motor board manufacturer
goes out of business? Or, discontinues that model? Or, makes
a change to the implementation that somehow doesn't work with
*your* application?
[I know a company that regularly scours eBay and ham fests for
old kit on which they have based their products -- kit that is
no longer available in regular channels! <shudder>]
Mackie couldn't make the MDR24/96 and sell it for $2,000 if they had to
design their own motherboard rather than using an Intel style one. They
chose well, I thought, buying an industrial grade board for about $400
rather than an Asus or whatever was around at the time for $100, and
failures have been very rare, and replacements were available for a long
time. But still, that board was based on standard technology of the day.
It was only better than a run-of-the-mill one because they tested better
and used better components.
Again, it depends on what they needed from that board/design.
My network speakers don't need serial or parallel ports, nor
a display, keyboard, mouse. Nor a disk drive. Nor a PCI
expansion bus. Nor megabytes of RAM, etc.
What often happens is people "pick" something and then try
to rationalize additional uses that they might not have
originally intended: "We can hook up a printer and print song
lists!" "We can interface to a MIDI device!" "We can transfer
files over the network!" All might be desirable features
but you are paying for them even if you don't use them (and
paying MORE, if you *do* -- as they need to be implemented
and maintained).
Contrast this with a commercial computer that might be the heart of a
studio's recorder and mixer. You can't buy a Dell one month and another
one a couple of months later and expect them to have the same
motherboard components. Sure, both of them will run Windows, but they
may have different Firewire chips (or no Firewire chip at all) and your
Firewire audio interface won't work the newer one.
You face this every time you bring someone else's technology
into your product. They could use the *same* Firewire chips
only to discover that the chip manufacturer updated their
masks and the chips now behave slightly differently! (that's
one reason chips have date codes)
Our $100 Zoom recorders are practical because the photography business
buys enough flash memory cards that they're dirt cheap. Our hard disk
recorders are practical because for many years, IDE drives could be
bought for well under $100 because there were so many general purpose
computers that used them.
The RADAR 24 track hard disk recorder runs under Linux and prices start
at about $7500. Some people are still buying them. The Alesis HD24
(recently discontinued) used a disk format that nobody can read. You
want WAV files? You have to go through the recorder or an accessory dock
(discontinued way too soon). But it allowed them to make a recorder that
used cheaper parts than the Mackie but still cost about the same.
So, yeah, there are people who are being somewhat innovative, but it
just doesn't pay in this particular market. And when something based on
unique technology dies, you're really sunk if you bought one. But at
least it didn't cost much, and if you were diligent about backing up and
migrating your data, you could use the data from one system on another
system - because the companies were forward thinking enough to
accommodate an audio file format specified by Microsoft that will
probably be around as long as cockroaches (but maybe not for 1,000 years).
WAV format limits the size of the "piece" you can record (about 1 hr
at 192/24/mono). Stuff 16 channels in that container and you're
down to ~5 minutes. I.e., you are forced to record multiple
channels in multiple files -- and still limited to ~1 hr.
There's absolutely nothing wrong with "special formats" -- as
long as they are documented as such! Nowadays, if you had
data on a medium in damn near *any* bizarre format, it would
be relatively trivial to convert that data to another form
AS LONG AS THE ORIGINAL FORMAT WAS DOCUMENTED. If this was
a common piece of kit, you can be *assured* someone would
have done it, already!
"This OS doesn't support volumes larger than XXX bytes. I guess
we'll have to find *another* OS for the GizmaCorder 2" (which
means the newer folks working on GizmaCorder 2 will tend not
to ever see any of the internals of GizmaCorder 1 -- at least
never with an eye towards supporting the G1!
OTOH, if G2 was largely G1 with new and improved features
(higher sampling rates, wider samples, more channels plus
a new set of "effects") then the G2 designers would have
been intimately familiar with the G1 *as* they adapted it
to the G2 and could, then, support the G1 as needed. I.e.,
then support becomes a marketing/political issue instead of
a technical consequence of design!
Easy to say, but it doesn't always work like that in practice. You have
to be able to adopt to the technology that's available when you design
the product unless you want to take responsibility for sustaining and
extending the technology. Commercial products that are based on Linux,
for instance the Harrison digital consoles, might be supportable for a
long time because they control the operating system. But they may need
to make extensive changes to it in order to support a motherboard that
they can buy 10 years after the initial design. They're in the console
business, not the motherboard business.
Look at their choices:
- avoid digital technology altogether (stick with an all-analog console)
- use third party technology (and be beholding to those third parties)
- develop your own technology (gives you free reign over its direction)
- embrace some other "public" technology and develop the skills
required to support it (in the event it fizzles out, heads off in
a different direction, or doesn't attend to your particular needs)
I have first hand experience with companies that relied on 3rd party
technology and then were forced out of certain markets (which they
held controlling interests!) simply because the third party decided
not to keep *supplying* the product in question. (In one case, the
"product" was a piece of software. All the 3rd party would have
had to do was grant additional licenses -- for $$$$ -- to allow the
product to continue to be available!)
I try to take the 3rd or 4th options (above) with products. I don't
want to be stuck in the past (option 1) with my hands tied, needlessly.
Nor do I want to invest lots of time and money in a design only to
have someone else act as "gatekeeper" for my exploiting that investment
(option 2).
E.g., the network speakers straddle the option 3 and 4 boundary as
much of the CODEC design I borrowed -- along with ideas for the
peer-based recovery protocol and the time synchronization protocol.
Yet, the mechanisms that I developed to "protect" the device in
a potentially "non-benign" environment are completely unique. As
is the overall design of the "system".
.
- Prev by Date: Re: Nearly OT: VF16 harddisk source
- Next by Date: Re: Speaking of audiophile weirdness again
- Previous by thread: Re: Nearly OT: VF16 harddisk source
- Next by thread: Re: Nearly OT: VF16 harddisk source
- Index(es):
Relevant Pages
|
