Please note that User Registration has been temporarily disabled due to a recent increase in automated registrations. If anyone needs an account, please request one here: RequestAccount. Thanks for your patience!--Wmat (talk)
Please email User:Wmat if you experience any issues with the Request Account form.

Difference between revisions of "EBC Exercise 18 Using the DSP for Audio Processing"

From eLinux.org
Jump to: navigation, search
m (Initial page)
 
m
Line 2: Line 2:
 
[[Category:EmbeddedBeagleClass]]
 
[[Category:EmbeddedBeagleClass]]
  
In the previous exercise you saw how to bring audio into the Beagle and send it out again. You also did some processing on the audio.  All this was done on the ARM processor.  The [http://focus.ti.com/docs/prod/folders/print/dm3730.html DM3730] on the BeagleBoard has both an ARM processor
+
In the previous exercise you saw how to bring audio into the Beagle and send it out again. You also did some processing on the audio.  All this was done on the ARM processor.  The [http://focus.ti.com/docs/prod/folders/print/dm3730.html DM3730] on the BeagleBoard has both an ARM processor and a C64x fixed-point DSP.  This exercise shows you how to use the DSP via [http://processors.wiki.ti.com/index.php/Introduction_to_C6Run c6run]. C6Run is a set of tools which will take in C files and generate either an ARM executable, or an ARM library which will leverage the DSP to execute the C code.
 +
 
 +
There are two uses of C6Run, exposed through two different front-end scripts. They are called '''C6RunLib''' and '''C6RunApp'''. We focus on C6RunLib here.
 +
 
 +
=== Examine the Files ===
 +
 
 +
* Copy the AudioThru files from [http://www.rose-hulman.edu/~yoder/Beagle/exercises/ here] to your Beagle.
 +
* Change directories to AudioThru/lab06d_audio_c6run.
 +
 
 +
<pre>
 +
# cd lab06d_audio_c6run
 +
# ls
 +
</pre>
 +
These are the same files as used in audio thru lab.  The files audio_process.c and audio_process.h are new.  audio_thread.c has been changed slightly. Makefile is completely different.
 +
 
 +
Edit autio_thread.c and search for audio_process. There are two occurrences.  I'll talk about the first on later, go to the second.
 +
<pre>
 +
$ gedit audio_thread.c
 +
 
 +
audio_process((short *)outputBuffer, (short *)inputBuffer, blksize/2);
 +
 
 +
</pre>
 +
I've replaced the call to memcpy() with the call to audio_process.  Pointers to the input and output buffers are passed along with the number samples in the buffers.  Note blksize is the number of '''chars''' in the buffers.  We're working with 16-bit samples, so everything is converted to shorts.
 +
 
 +
Look in audio_process.c.  Presently all it does is a memcpy() when called.
 +
 
 +
=== Make ===
 +
 
 +
Before the first make the paths need to be set up.  Do this:
 +
<pre>
 +
$ source ~/c6run_build/environment.sh
 +
$ source ~/c6run_build/loadmodules.sh
 +
</pre>
 +
The first source
 +
 
 +
There are 3 groups of files here.  The source code (*.c and *.h), object files for running on the ARM (gpp) only (audioThru_arm, gpp, gpp_lib) and objects files for running on the DSP (audioThru_dsp, dsp, dsp_lib).  What's significant is that the same source code produced both sets of objects (dsp, gpp).  It's how the source is compiled determines where it is run. 
 +
 
 +
== Running ==
 +
 
 +
Run the apps.
 +
<pre>
 +
# ./audioThru_arm
 +
# ./audioThru_dsp
 +
</pre>
 +
Both will run until you hit '''ctrl-C'''. To hear something you need to hookup your mp3 player to the input on the Beagle and speakers to the output.
 +
 
 +
Once you are sure it is working, try building everything from scratch.
 +
<pre>
 +
# make clean
 +
# make
 +
</pre>
 +
By default '''make''' creates both the ARM only and DSP objects.  make takes about 20 seconds on my Beagle.
 +
 
 +
== Experiment with the code ==
 +
 
 +
Now that you have something working, play around a bit.  git is installed so you can preserve the present contents of the files with:
 +
<pre>
 +
# git add Makefile audio_input_output.c audio_process.c audio_thread.c
 +
# git commit -m "Initial commit"
 +
</pre>
 +
If needed you can use git to retrieve the original version of the files.
 +
 
 +
Things to try:
 +
 
 +
* There are places in the code where timing can be displayed.  Remove the comments and display the times.  How often is the main loop executed?  How long does the DSP take? What's the overhead for the DSP?
 +
* Try making the DSP do more than pass through.  Zero out the left channel to be sure it is working.
 +
* Try changing the sampling rate and buffer sizes.  What setting cause the buffers to overflow or underflow?
 +
* Implement your own processing on the DSP.  Do a simple FIR lowpass filter, etc.
 +
* Switch the input to the microphones on the web cam and listen to your voice.

Revision as of 20:10, 24 August 2011


In the previous exercise you saw how to bring audio into the Beagle and send it out again. You also did some processing on the audio. All this was done on the ARM processor. The DM3730 on the BeagleBoard has both an ARM processor and a C64x fixed-point DSP. This exercise shows you how to use the DSP via c6run. C6Run is a set of tools which will take in C files and generate either an ARM executable, or an ARM library which will leverage the DSP to execute the C code.

There are two uses of C6Run, exposed through two different front-end scripts. They are called C6RunLib and C6RunApp. We focus on C6RunLib here.

Examine the Files

  • Copy the AudioThru files from here to your Beagle.
  • Change directories to AudioThru/lab06d_audio_c6run.
# cd lab06d_audio_c6run
# ls

These are the same files as used in audio thru lab. The files audio_process.c and audio_process.h are new. audio_thread.c has been changed slightly. Makefile is completely different.

Edit autio_thread.c and search for audio_process. There are two occurrences. I'll talk about the first on later, go to the second.

$ gedit audio_thread.c

	audio_process((short *)outputBuffer, (short *)inputBuffer, blksize/2);

I've replaced the call to memcpy() with the call to audio_process. Pointers to the input and output buffers are passed along with the number samples in the buffers. Note blksize is the number of chars in the buffers. We're working with 16-bit samples, so everything is converted to shorts.

Look in audio_process.c. Presently all it does is a memcpy() when called.

Make

Before the first make the paths need to be set up. Do this:

$ source ~/c6run_build/environment.sh
$ source ~/c6run_build/loadmodules.sh

The first source

There are 3 groups of files here. The source code (*.c and *.h), object files for running on the ARM (gpp) only (audioThru_arm, gpp, gpp_lib) and objects files for running on the DSP (audioThru_dsp, dsp, dsp_lib). What's significant is that the same source code produced both sets of objects (dsp, gpp). It's how the source is compiled determines where it is run.

Running

Run the apps.

# ./audioThru_arm
# ./audioThru_dsp

Both will run until you hit ctrl-C. To hear something you need to hookup your mp3 player to the input on the Beagle and speakers to the output.

Once you are sure it is working, try building everything from scratch.

# make clean
# make

By default make creates both the ARM only and DSP objects. make takes about 20 seconds on my Beagle.

Experiment with the code

Now that you have something working, play around a bit. git is installed so you can preserve the present contents of the files with:

# git add Makefile audio_input_output.c audio_process.c audio_thread.c
# git commit -m "Initial commit"

If needed you can use git to retrieve the original version of the files.

Things to try:

  • There are places in the code where timing can be displayed. Remove the comments and display the times. How often is the main loop executed? How long does the DSP take? What's the overhead for the DSP?
  • Try making the DSP do more than pass through. Zero out the left channel to be sure it is working.
  • Try changing the sampling rate and buffer sizes. What setting cause the buffers to overflow or underflow?
  • Implement your own processing on the DSP. Do a simple FIR lowpass filter, etc.
  • Switch the input to the microphones on the web cam and listen to your voice.