New to DSP implementation

Hi All,

    	I am in my 3rd year of electrical engineering and I am about to start 
my first "real" project. I want to build a device that will take raw audio 
input (from a file, not live) and compress/encode it into mp3 format. I 
want everything to be done in hardware, with just usb interfaces for the 
input and output.

I guess what I am asking is, where do I start? :)

I have been given a $150 budget, so unfortunately buying one of those nice 
Analog Device's development boards is out of the question.

Thoughts?

"Dan Gingera" <parabol@shaw.ca> wrote in message
news:Xns9B89A1CB44DBCparabolshawca@69.16.185.250...
> Hi All,
>
>     I am in my 3rd year of electrical engineering and I am about to start
> my first "real" project.  I want to build a device that will take raw
audio
> input (from a file, not live) and compress/encode it into mp3 format. I
> want everything to be done in hardware, with just usb interfaces for the
> input and output.
> I guess what I am asking is, where do I start? :)

www.google.com

> I have been given a $150 budget, so unfortunately buying one of those nice
> Analog Device's development boards is out of the question.

:))))))

Buy a used PC laptop.

VLV

Dan Gingera <parabol@shaw.ca> wrote:
 
>        I am in my 3rd year of electrical engineering and I am about to start 
> my first "real" project. I want to build a device that will take raw audio 
> input (from a file, not live) and compress/encode it into mp3 format. I 
> want everything to be done in hardware, with just usb interfaces for the 
> input and output.

What do you mean by "done in hardware?"
 
> I guess what I am asking is, where do I start? :)

Usual for comp.dsp is to use DSP chips, or at least standard
microprocessors.  If you want, for example, an FPGA implementation
then you might try comp.arch.fpga.  Even so, many such designs
will still be programmed.  Most processors now are microprogrammed,
so some might say not "done in hardware."

And most hardware designs now are done in VHDL or verilog,
which some might consider programming languages and not
"done in hardware."

-- glen

On Jan 4, 6:54&#4294967295;pm, Dan Gingera <para...@shaw.ca> wrote:
>
> &#4294967295; &#4294967295; &#4294967295; &#4294967295; I am in my 3rd year of electrical engineering and I am about to start
> my first "real" project. I want to build a device that will take raw audio
> input (from a file, not live) and compress/encode it into mp3 format. I
> want everything to be done in hardware, with just usb interfaces for the
> input and output.
>
> I guess what I am asking is, where do I start? :)

oh geez.  even putting together code to adequately implement the USB
communication protocol would be a little mess.  i think, for practical
purposes, you need to settle what it would take to yank the audio out
of a usb packet (and to deal with the other kinds of usb chunks of
info), put it in a buffer as pcm data, and back out again as usb-
coded, you got half of the problem licked.  the other half is doing
the mp3 coding.

> I have been given a $150 budget, so unfortunately buying one of those nice
> Analog Device's development boards is out of the question.
>
> Thoughts?

i suppose that ADI might have bench mp3 code, but i dunno if it's
either free or in the public domain or not.  so you might have to get
something like "the red book" (but for mp3, i dunno what color it
would be).  an exhaustive or official definition of the standard.

now here's the funny thing about the $150 budget and how i think your
school might be thinking: i think they are thinking about this with
the bias of a hardware engineer.  it's likely the such a device could
be assembled for less than $150 parts (DSP, maybe USB I/O device).
but you gotta code them unless this has been done so often that
somewhere on the web there is such code lying around.

now, your school should (if they're expecting to have you do this for
$150) have a development system for at least some subset of these the
ADI (or someone else's) DSPs.  you could program stuff on this dev
system before putting it on PROM for this <$150 target device.  but if
you don't have something like that already in your infrastructure,
then i dunno how they can expect you to do this for $150.

r b-j

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote in
news:gjrsmf$jfu$2@naig.caltech.edu: 

> Dan Gingera <parabol@shaw.ca> wrote:
>  
>>        I am in my 3rd year of electrical engineering and I am about
>>        to start 
>> my first "real" project. I want to build a device that will take raw
>> audio input (from a file, not live) and compress/encode it into mp3
>> format. I want everything to be done in hardware, with just usb
>> interfaces for the input and output.
> 
> What do you mean by "done in hardware?"


I guess what I mean to say is that there will be no user-defined options or 
gui. Just the code on the DSP chip itself, and essentially a simple 
"start" button to initiate the compression process.

On Jan 4, 9:51&#4294967295;pm, Dan Gingera <para...@shaw.ca> wrote:
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote innews:gjrsmf$jfu$2@naig.caltech.edu:
>
> > Dan Gingera <para...@shaw.ca> wrote:
>
> >> &#4294967295; &#4294967295; &#4294967295; &#4294967295;I am in my 3rd year of electrical engineering and I am about
> >> &#4294967295; &#4294967295; &#4294967295; &#4294967295;to start
> >> my first "real" project. I want to build a device that will take raw
> >> audio input (from a file, not live) and compress/encode it into mp3
> >> format. I want everything to be done in hardware, with just usb
> >> interfaces for the input and output.
>
> > What do you mean by "done in hardware?"
>
> I guess what I mean to say is that there will be no user-defined options or
> gui. Just the code on the DSP chip itself, and essentially a simple
> "start" button to initiate the compression process

How about something like what can be found at this link:

http://www.linuxdevices.com/news/NS6372429785.html

Notice the two USB ports. Also, you may be able to use a Linux
application called "sox" (i.e., Sound Exchange) to do your conversion
to mp3. For easy verification, you could compare the results of your
custom software to the "sox" output.

Darol Klawetter

Dan Gingera wrote:

> I have been given a $150 budget, so unfortunately buying one of those nice 
> Analog Device's development boards is out of the question.
> 
> Thoughts?

www.beagleboard.org has a nice Omap3 dev-board for $149. You also need 
to cables and a SD-card to use it, so you are slightly over your budget.

But you get a beefy TI fixed-point DSP, a very nice general purpose CPU 
and all the IO you need for the money.

The problem is: It runs linux, so all you have to do is to glue together 
an mp3-encoder-lib, audio-in via also and usb-io. If you have some linux 
experience that's an rediculous easy task.

Nils

Nils  <n.pipenbrinck@cubic.org> wrote:

>Dan Gingera wrote:

>> I have been given a $150 budget, so unfortunately buying one of those nice 
>> Analog Device's development boards is out of the question.
>> 
>> Thoughts?

>www.beagleboard.org has a nice Omap3 dev-board for $149. You also need 
>to cables and a SD-card to use it, so you are slightly over your budget.

>But you get a beefy TI fixed-point DSP, a very nice general purpose CPU 
>and all the IO you need for the money.
>
>The problem is: It runs linux, so all you have to do is to glue together 
>an mp3-encoder-lib, audio-in via also and usb-io. If you have some linux 
>experience that's an rediculous easy task.

It's a class project, so you can avoid the problem of the
task being too easy by writing an mp3 encoder from scratch,
and even showing how you've researched audio compression 
assumptions in the encoder.

I'd say the main problem is the opposite one -- getting bogged
down in the I/O implementation.  But that also is a learning
experience.

Steve

> I guess what I am asking is, where do I start? :)
>
> Thoughts?

If you want to implement a full MP3 encoder/decoder for a project you
need to approach this from the systems point of view.  Meaning that
you are integrating a bunch of different technologies and you need to
understand each of those technologies but not implement them.

You can start with an open-source version of the MP3 encoder/decoder
like, http://www.underbit.com/products/mad/.  Which ever encoder/
decoder software you use (others available as well) determine how much
CPU you need.  After that, find a development board with integrated
USB and enough horse power.  You will probably have to deal with Full
speed USB, 12Mbit/sec.  There are many boards available with general
purpose CPUs from Atmel, Phillips, Silicon Labs etc.

As mentioned, the USB portion is probably enough work, but you can
find information for a USB audio class on google and examples from
different silicon providers.  If you integrate the USB audio class you
will have no work to do on the host side (Windows or Linux).

Good Luck.

Steve Pope wrote:

> 
> It's a class project, so you can avoid the problem of the
> task being too easy by writing an mp3 encoder from scratch,
> and even showing how you've researched audio compression 
> assumptions in the encoder.

Good point. Getting the kernel installed, getting a cross-compiler 
working and dealing with the quirks of automake/autoconf will take you 
busy for a couple of weeks, especially if you don't work 8h/day.

> I'd say the main problem is the opposite one -- getting bogged
> down in the I/O implementation.  But that also is a learning
> experience.

Agreed. If I think about it: If you do such stuff, e.g. linking 
lame+libusb+alsa+gluecode and getting a linux kernel compile + configure 
the system, for the first time, and you don't have anyone who will hold 
your hand and solve your problems it's quite a task.

Nils