From: john slee <indigoid@higherplane.net>
To: Rob Landley <landley@trommello.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: New Scheduler and Digital Signal Processors?
Date: Wed, 2 Jan 2002 18:39:42 +1100 [thread overview]
Message-ID: <20020102183942.A14169@higherplane.net> (raw)
In-Reply-To: <20020101050208.OMXO20896.femail24.sdc1.sfba.home.com@there>
In-Reply-To: <20020101050208.OMXO20896.femail24.sdc1.sfba.home.com@there>
On Mon, Dec 31, 2001 at 04:00:26PM -0500, Rob Landley wrote:
> DSP is just a processor designed to do I/O. It runs a program telling it how
> to convert input into output. Ooh. This is half of unix programming, and
> why we have the pipe command, only now you can unload each pipe stage on a
thats all well and good if whatever is on the output side of the dsp is
the final destination for your data but surely bouncing it around
between all those dsp chips is going to take time...
> dedicated coprocessor, so you can program your sound output chip to do speech
> synthesis or decompress MP3's. And latency becomes way less of a problem if
> you can dedicate a processor to it. (Think of a DMA channel that can run a
> filter program on the data it's transporting, and boom: you've got a DSP.)
> In theory, anything you can write as a filter that sits on a pipe could be
> done by a DSP, and in the Unix philosophy that's just about everything.
i have a high-end-ish soundcard that has four analogdevices SHARC DSPs
on it. using the (unfortunately windows/mac only) software you upload
synth/effects code to it, draw your signal routing on teh screen, then
control it through midi ports on the back of the card... (or with cubase
or similar.)
its a great system, and as you allude to the latency is fantastically
low. for more info, see http://www.creamware.com/. my card is a bit
old (the "pulsar" model) but all of their cards are built on the same
platform. i believe that with their proprietary bus and more expensive
cards you can use up to 45 SHARCs as one huge synth engine.
these days people are doing much the same thing in software (witness
cubase VST, buzz, fruityloops, rebirth, reason, logic, etc etc) but
while today's athlons et al. are getting fast enough for it there's a
few nice aspects of the dsp solution that make it a clear winner (in my
eyes at least). such as not hearing clicks/jitter when you move the
mouse too rapidly...
j.
--
R N G G "Well, there it goes again... And we just sit
I G G G here without opposable thumbs." -- gary larson
next prev parent reply other threads:[~2002-01-02 7:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-31 21:00 New Scheduler and Digital Signal Processors? Rob Landley
2002-01-01 7:21 ` Timothy Covell
2002-01-01 10:25 ` Alan Cox
2002-01-01 19:37 ` Davide Libenzi
2002-01-02 7:39 ` john slee [this message]
2002-01-02 16:06 ` Jesse Pollard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020102183942.A14169@higherplane.net \
--to=indigoid@higherplane.net \
--cc=landley@trommello.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox