Mailing List Archive: Maemo: Developers

DSP programming

Index | Next | Previous | View Threaded

ananaza at iki

Jan 18, 2006, 1:11 AM

Post #1 of 8 (3220 views)
Permalink

DSP programming

I just took a brief look at what is required for programming for the
DSP in the 770. It seems that building your own modules is possible
with publically awailable tools and documents. At least I got the
demo_console from DSP gateway loaded and it seems to run OK.

The following is what I did. Someone might be interested in testing
the instructions and maybe polish these into a proper HOWTO to the
maemo wiki.

1. Get TI Linux DSP tools from:

https://www-a.ti.com/downloads/sds_support/targetcontent/LinuxDspTools/index.html

Access to the download requires creating an account.

The download page has a link to a "Getting Started" PDF which has
instructions for installing. The install instruct start at page 11,
chapter 2.3.1. The download package is an ELF-executable but
fortunately it just unpacks the main package. The package seems to
require java - at least it prints out "Searching for Java(tm) Virtual
Machine". For other pre-requirements see chapter 2.1, but note that
not all of the listed things are strictly required. Installing pdksh
might be a good idea if one does not want to go changing the scripts
written for ksh.

For easily installing the unpacked subpackages one can use the
supplied expect script. Naturally this requires having expect
installed. Alternatively one can simply unpack the tarballs one by
one. It is probably a good idea to use the same directory names as the
ones used in the instructions in order to minimize needed chages to
DSP gateway makefiles.

The instructions starting from chapter 3 seem to be MontaVista and
dsplink specific. If one wants to use the dsp gateway there's no need
to follow those.

2. Get dsp gateway from http://dspgateway.sourceforge.net/pub/index.php

Get both the arm side package (dspgw-3.3-arm.tar.bz2) and the dsp side
package (dspgw-3.3-dsp.tar.bz2). No need to go patching the 770 kernel
or rebuilding it. Unpack the tarballs. Go to
dspgw-3.3-arm/host_utils/mod_utils and build the coff_unresolve and
gen_dummy_kernel tools. Simple make should be sufficient. Either copy
these tools to your path or adjust
dspgw-3.3-dsp/apps/demo_mod/Makefile to use the tools from the
directory where they are. Also build the arm side of the demo console
in dspgw-3.3-arm/apps/demo with "make demo_console". You may need to
adjust CC to point to your arm cross compiler, e.g.
/scratchbox/compilers/arm-gcc-3.3.4-glibc-2.3.2/bin/arm-linux-gcc if
you have scratchbox installed.

3. Get the avs_kernel.out from your 770

The dynamically loaded DSP modules are linked against a dummy kernel
object generated from the actual kernel. The DSP kernel is in /etc/dsp
directory. Just copy it to your host and adjust
dspgw-3.3-dsp/apps/demo_mod/Makefile to use the 770 avs_kernel.out to
generate the dummy_kernel.obj instead of using the default
tinkernel.out. Now you should be able to build the DSP side of the
demo console with simple make.

4. Install demo_console

In order to make the DSP gateway dynamic loader to load the DSP side
of the demo, we need to add a line to the /etc/dsp/dsp_dld_avs.conf
file. So e.g.

# cp -i /media/mmc1/demo_console.o /etc/dsp/modules
# echo "demo_console _task_demo_console 1 /etc/dsp/modules/demo_console.o" \
>> /etc/dsp/dsp_dld_avs.conf

I was not able to restart the DSP gateway dynamic loader (there is an
init script for dld) so I just rebooted my 770. After boot there
should be a /dev/dsptask/demo_console if the dld managed to load the
module.

Now just run the arm side demo_console. You should see some praise :-)

--
http://www.iki.fi/~ananaza/

_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

ed at okerson

Jan 18, 2006, 2:26 AM

Post #2 of 8 (3127 views)
Permalink

Re: DSP programming [In reply to]

> I was not able to restart the DSP gateway dynamic loader (there is an
> init script for dld) so I just rebooted my 770. After boot there
> should be a /dev/dsptask/demo_console if the dld managed to load the
> module.

'killall dsp_dld' will also work without having to reboot. The dsme
daemon will restart dsp_dld automagically.

Ed

_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

S.G.Pickering at bath

Jan 17, 2007, 3:23 AM

Post #3 of 8 (2733 views)
Permalink

RE: DSP programming [In reply to]

I've been trying to get started with DSP programming, following the
instructions summarised in this post.

> I just took a brief look at what is required for programming
> for the DSP in the 770. It seems that building your own
> modules is possible with publically awailable tools and
> documents. At least I got the demo_console from DSP gateway
> loaded and it seems to run OK.
>
> The following is what I did. Someone might be interested in
> testing the instructions and maybe polish these into a proper
> HOWTO to the maemo wiki.

<snip>

> 3. Get the avs_kernel.out from your 770
>
> The dynamically loaded DSP modules are linked against a dummy
> kernel object generated from the actual kernel. The DSP
> kernel is in /etc/dsp directory. Just copy it to your host
> and adjust dspgw-3.3-dsp/apps/demo_mod/Makefile to use the
> 770 avs_kernel.out to generate the dummy_kernel.obj instead
> of using the default tinkernel.out. Now you should be able to
> build the DSP side of the demo console with simple make.

After building the dsp side of the demos (demo_console or demo_fb), the next
step should be to run coff_unresolve on the resultant .out file, to remove
the dummy kernel, which has been linked in. So something like the following:

# create the dummy kernel
gen_dummy_kernel avs_kernel.out -o avs_kernel.obj

# Run make for the dsp demo in question
# (compiles source and statically links in
# the avs_kernel.obj dummy kernel)
make

# remove the dummy kernel
coff_unresolve -s .tinkernel demo_console.out

Unfortunately, the code produced using this technique doesn't run. It
results in the eventual error message:

open: Device or resource busy

This is the same message as is received if you actually forget to run
coff_unresolve on the demo_console.out dsp task.

What does work, however, is simply renaming the unlinked demo_console.obj
file and placing that in the /lib/dsp/modules/ directory.

Have other people seen this problem? Has anyone else tried? I'd specifically
like to work out whether it's me making a mistake with coff_unresolve (as
this step will certainly be necessary for dsp tasks which are built using
more than one source file, as these can't be linked together without the
dummy kernel (avs_kernel.obj)).

Thanks,

Simon

P.S. The above steps are documented in the dsp_dld_spec13.pdf file from
dspgateway, in Chapter 5., "Building a DSP dynamic task module".

_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

S.G.Pickering at bath

Jan 19, 2007, 4:45 AM

Post #4 of 8 (2724 views)
Permalink

RE: DSP programming [In reply to]

Not sure whether anyone is particularly interested in this stuff, but here
goes.

> After building the dsp side of the demos (demo_console or demo_fb),
> the next step should be to run coff_unresolve on the resultant .out
> file, to remove the dummy kernel, which has been linked in. So
> something like the following:
>
> # create the dummy kernel
> gen_dummy_kernel avs_kernel.out -o avs_kernel.obj
>
> # Run make for the dsp demo in question # (compiles source and
> statically links in # the avs_kernel.obj dummy kernel) make
>
> # remove the dummy kernel
> coff_unresolve -s .tinkernel demo_console.out
>
> Unfortunately, the code produced using this technique doesn't run. It
> results in the eventual error message:
>
> open: Device or resource busy
>
> This is the same message as is received if you actually forget to run
> coff_unresolve on the demo_console.out dsp task.
>
> What does work, however, is simply renaming the unlinked
> demo_console.obj file and placing that in the /lib/dsp/modules/
> directory.

I've tried this with the hellotimer demo from the dsp_dld_spec13.pdf
document. I think I've narrowed my issues down to the particular memory
region I'm trying to use (i.e. it overlaps with something already there), as
well as the slight confusion about which .cmd file it reads its memory
location from.

In the case of the hellotimer demo, the linking stage is required as
otherwise there's no way to get the memory location information into the
task. The plain demo_console presumably doesn't use local variables so
doesn't need this information and can run from an unlinked object file. My
previous problems may have been caused by my trying to give it a memory
address that I'd not mapped, and that I couldn't map as it overlapped.

I get the following output from the linked hellotimer task:

# ./hellotimer 5
Cannot open /dev/dsptask/hellotimer

# dspctl start hellotimer.out
Loading hellotimer.out...
.text : adr = 0x800000, size= 331 ...initialization failed!!
Can't determine reset vector address

This is a bit confusing as in the hellotimer.cmd file the MEMORY section
states:

MEMORY {
EXRAM_HELLO: origin = 0x30000, len = 0x1000 } SECTIONS { .text {} >
EXRAM_HELLO }

But the output of "dspctl start" seems to indicate that it's trying to place
it at the ROM location (as specified in the dummy.cmd file, which is also
linked in - I'll try removing this to see if it helps):

MEMORY {
RAM: origin = 0x000000, len = 0x800000
ROM: origin = 0x800000, len = 0x800000
}

(note the sections must be named with MEMORY in capitals otherwise it gets
confused, this is not the case in the .pdf file).

I think this address is already used (perhaps by the DSP ROM mapping, though
that may not actually be the case for the 770) and so if I do as the FAQ
suggests (http://dspgateway.sourceforge.net/pub/index.php?Page=FAQ#Q7) and
map some memory at this address (using "dspctl exmap 800000 100000" for
example), the dsp decides it's had enough and causes a reset.

One addition point for anyone compiling these examples is that the clk.a55l
library specified in the Makefile is not present in the Linux Ti toolchain.
I'm guessing that this is a packaging error (as the header file exists) and
will contact Ti to query this omission (it's already in the avs_kernel.out
so I'm hoping it won't make any difference as I hope I won't need to link in
the additional libraries in this case). I also note that the Makefile
specifies the libraries with an 'l' (little 'L') on the end (meaning large
memory model), while in a case-sensitive Linux filesystem they actually
appear with 'L' (large 'L') so the Makefile won't find them.

Time to look at "dmesg" and "/sys/device/platform/dsp/mmu" to see if I can
work out whether my memory location is at fault.

Cheers,

Simon

_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

S.G.Pickering at bath

Jan 22, 2007, 9:41 AM

Post #5 of 8 (2727 views)
Permalink

RE: DSP programming [In reply to]

> I get the following output from the linked hellotimer task:
>
> # ./hellotimer 5
> Cannot open /dev/dsptask/hellotimer
>
> # dspctl start hellotimer.out
> Loading hellotimer.out...
> .text : adr = 0x800000, size= 331 ...initialization failed!!
> Can't determine reset vector address
>
> This is a bit confusing as in the hellotimer.cmd file the
> MEMORY section
> states:
>
> MEMORY {
> EXRAM_HELLO: origin = 0x30000, len = 0x1000 } SECTIONS {
> .text {} > EXRAM_HELLO }
>
> But the output of "dspctl start" seems to indicate that it's
> trying to place it at the ROM location (as specified in the
> dummy.cmd file, which is also linked in - I'll try removing
> this to see if it helps):
>
> MEMORY {
> RAM: origin = 0x000000, len = 0x800000
> ROM: origin = 0x800000, len = 0x800000
> }
>

Okay, so removing the dummy.cmd file (the linker command file) removes this
issue and I get the following:

Nokia770-39:/home/user# dspctl start hellotimer.out
loading hellotimer.out...
.text : adr = 0x000100, size= 331 ... initialized.
.data : adr = 0x010000, size= 0
.bss : adr = 0x010000, size= 44 ... initialized.
.const : adr = 0x00024c, size= 126 ... initialized.
warning: found zero-sized cinit entry at 0x22
.cinit : adr = 0x000000, size= 36 ... .bss variables are
initialized.
setting DSP reset vector to 0x000000
releasing DSP reset
DSP configuration ... failed
Device or resource busy

Then a lifeguard reset.

So still some issue, but at least the memory thing looks just about okay.
Not sure the reset vector should be 0x000000 though.

The dsplink examples generally include both the tokliBIOS.cmd and
tokliBIOScfg.cmd linker command files. I think the latter corresponds to the
avs_kernelcfg.cmd file which is found in /lib/dsp/ (and should also
correspond to the stripped down dummy.cmd file, which caused some issues
above, according to one of the dsplink examples). If this is the case, I
wonder why both are needed (as the avs_kernelcfg.cmd file contains all of
the contents of the tokliBIOS.cmd file, just with differing values).
Presumably this would be different had I just built the kernel from the
source code, or perhaps the avs_kernelcfg.cmd file has had everything added
to it for convenience?

Linking with the avs_kernelcfg.cmd file produces lots of warnings, as I have
to comment out at least the clk.a55L library as it's not present in the Ti
DSP toolchain for Linux (any pointers to a location for this file
appreciated), and other than that, and the fact that coff_unresolve -s
.tinkernel hellotimer.o leaves lots of extra sections behind, the behaviour
is the same as the previous one:

Anyone have any ideas as to what is causing the reset? How can I query the
DSP to find out what's wrong (other than a very quick 'cat
/sys/devices/platform/dsp/err' iirc)? I hope I'm not chasing the wrong thing
here, fiddling about with the avs_kernelcfg.cmd file, and that there's not
something more fundamental (and probably simple) wrong.

Any Ti gurus out there know how much of the avs_kernelcfg.cmd file is
required (or what extra)? I need to read-up on the reset vector.

Another aside, I find it interesting/odd that the demo_console.o file (this
is an unlinked object file) is able to run quite happily when called from
the arm binary, but that it can't be loaded using "dspctl start".

Nokia770-39:/home/user# dspctl start demo_console.out
loading demo_console.out...
Can't determine reset vector address

When linked it isn't interested (so something wrong with my linking commands
- I'll concentrate solely on this example now to save muddying the waters by
introducing new code).

Cheers,

Simon

P.S. Anyone know how I should contact Ti about the missing library? The
toolchain download page points to the Yahoo omap group (to which I've posted
a question), but the mailing list on that group appears to contain only
spam.

_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

S.G.Pickering at bath

May 11, 2007, 2:45 AM

Post #6 of 8 (2436 views)
Permalink

RE: DSP programming [In reply to]

Hi All,

I've had some time and have picked up where I left off, but this time using my
N800. The result is good news :) (but a rather long and meandering email). The
DSP seems very well behaved (no resets leading to reboots) and the couple of
demos I've tried worked fine. I was quite surprised after the hassles I had with
the 770. I don't know whether I've done something different or whether the setup
on the N800 (hardware/software) has helped.

Anyway, instructions largely as before, Ti toolchain all the same, etc.

I tested the demo_console and test7 demos, both worked fine.

I made my own Makefiles pointing to the locations of my toolchain. These are
available in the tarballs of the DSP code directories I've placed at
http://people.bath.ac.uk/enpsgp/nokia770/dsp/. They are copies of the ones from
the DSP_Gateway33_spec.pdf document. The code was also copied from here, but
it's available in the dspgw-3.3-dsp.tar.gz tarball from the DSP Gateway page.
You'll also need the ARM-side code which is in dspgw-3.3-arm.tar.gz.

A couple of notes at this point (about copying from the pdfs from the DSP
Gateway site): Any \ characters appears as a � in the pdfs and the " sometimes
comes out as a different character (smart quote) so make sure you check your
code if you start getting weird errors (the last one had me scratching my head
for a while as they look pretty much the same in my editor).

You'll also need to remove references to the <asm/arch/omapdsp.h> include file.
I don't have this, the tarball demos don't have this line either (and are
otherwise identical to the pdfs). No idea what it's for.

After compiling your code, you'll need to place the DSP-side object file (*.o)
in /lib/dsp/modules/, you'll also need to make an entry in the
/lib/dsp/dsp_dld_avs.conf file.

My addition lines looks like this:

demo_console _task_demo_console 1 /lib/dsp/modules/demo_console.o
test7 _task_test7 1 /lib/dsp/modules/test7.o

I didn't add the name of any cmd files to the last column in the conf file
(though this is shown in the pdf instructions), mainly because it said it's
optional, and because I didn't have one (or the source for one, etc.). I need to
clarify just how these are optional, and what they achieve when they are listed
in the conf file. Possibly overrides to the settings in the module itself?

You'll then want to run "dsp_dld" to reload the module list, but this will
complain that it can't find the conf file:

Nokia-N800-10:~# dsp_dld
sending SIGBUS signal to all task users...
killing pid 832.
killing pid 827.
killing pid 1582.
Can't open /lib/dsp/dsp_dld.conf

So you need to create a symlink from the actual file dsp_dld_avs.conf, to the
one it expects dsp_dld.conf (both in the /lib/dsp/ directory). Then try again
and you'll see something like this:

Nokia-N800-10:~# dsp_dld
sending SIGBUS signal to all task users...
killing pid 4234.
killing pid 4236.
killing pid 4235.
mapping external memory: adr = 0x028000, size = 0x1000
mapping external memory: adr = 0x100000, size = 0x200000
mapping external memory: adr = 0x400000, size = 0x180000
detected binary version 3.3.0.0
setting DSP reset vector to 0x10389e
releasing DSP reset
DSP configuration ...
succeeded.

Then run the ARM-side binaries and see results. E.g.:

Nokia-N800-10:~# ./test7
32 bytes written
32 bytes read
Aaaaabbbbbcccccdddddeeeeefffffgg

If you see a message like this:

Nokia-N800-10:~# ./demo_console
open: No such file or directory

It means you've either not added the module to the /lib/dsp/dsp_dld_avs.conf
file, or you've not run dsp_dld to refresh the DSP.

I also built the demo_fb demo, but couldn't get it to do anything as I couldn't
share the framebuffer. Using "dspctl fbexport" produces an error (better than
the resets of old), and there's no /proc/dsp/ or /sys/devices/platform/dsp/mmu
or mem entries to look at anymore to see whether my choice of address is wrong.
Obviously something's changed. There are also no longer any dsp tasks that
access the framebuffer. Perhaps this functionality has been disabled?

Anyway, the fact the demos work means that people can now happily experiment
with the DSP. It would be nice if Nokia could release a header file for any
sound related functions contained in the avs_kernel, so that we can link into
those rather than having to fiddle about and re-write a codec for the audio
hardware (though there is a demo on the Ti website that might be a good start -
DSP OGG sink on the DSP anyone?). Is this possible (releasing the header file) -
it may not be if this code belongs to a subcontractor, could we know one way or
the other?

I'm going to look at using the DSP with Octave (via oct files) for doing fast
ffts, etc. I'd also like to see whether it might help with speeding up JPEG
decoding, which leads me rather obliquely onto the IVA.

I've tried searching for this, but all I seem to get are promo. pdfs about how
it's included in various OMAPs, and how wonderful it is, but nothing about what
it actually is. For example, is it like the DSP, where it runs its own kernel,
or is it a chip with set functionality that would have a limited set of function
calls, etc.? Is there some technical documentation available for it anywhere? I
suppose this question may be better asked on the linux-omap-open-source mailing
list as some people there have been/are working on a DSP-IVA task bridge (e.g.
see http://komalshah.blogspot.com/), but I thought I'd tack it on here and see
whether anyone has run across anything.

Cheers,

Simon

_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

lbattraw at gmail

May 11, 2007, 4:59 AM

Post #7 of 8 (2436 views)
Permalink

Re: DSP programming [In reply to]

On 5/11/07, Simon Pickering <S.G.Pickering [at] bath> wrote:
> Hi All,
>
> I've had some time and have picked up where I left off, but this time using my
> N800. The result is good news :) (but a rather long and meandering email). The
> DSP seems very well behaved (no resets leading to reboots) and the couple of
> demos I've tried worked fine. I was quite surprised after the hassles I had with
> the 770. I don't know whether I've done something different or whether the setup
> on the N800 (hardware/software) has helped.

I've often wondered the same. With the 770 being essentially the
first off the line for the series if there weren't a fair number of
internal errata pages on hardware issues (internally) I'd be
surprised. The n800 has been so much more stable compared to it's
predecessor it does make you wonder.how many things did get fixed.

> Anyway, instructions largely as before, Ti toolchain all the same, etc.
>
> I tested the demo_console and test7 demos, both worked fine.
>
> I made my own Makefiles pointing to the locations of my toolchain. These are
> available in the tarballs of the DSP code directories I've placed at
> http://people.bath.ac.uk/enpsgp/nokia770/dsp/. They are copies of the ones from
> the DSP_Gateway33_spec.pdf document. The code was also copied from here, but
> it's available in the dspgw-3.3-dsp.tar.gz tarball from the DSP Gateway page.
> You'll also need the ARM-side code which is in dspgw-3.3-arm.tar.gz.
>
> A couple of notes at this point (about copying from the pdfs from the DSP
> Gateway site): Any \ characters appears as a � in the pdfs and the " sometimes
> comes out as a different character (smart quote) so make sure you check your
> code if you start getting weird errors (the last one had me scratching my head
> for a while as they look pretty much the same in my editor).
>
> You'll also need to remove references to the <asm/arch/omapdsp.h> include file.
> I don't have this, the tarball demos don't have this line either (and are
> otherwise identical to the pdfs). No idea what it's for.

It might be handy to have-- are the register names, configuration
register bits, etc. defined somewhere else? That'd be my guess right
off the bat.

> After compiling your code, you'll need to place the DSP-side object file (*.o)
> in /lib/dsp/modules/, you'll also need to make an entry in the
> /lib/dsp/dsp_dld_avs.conf file.
>
> My addition lines looks like this:
>
> demo_console _task_demo_console 1 /lib/dsp/modules/demo_console.o
> test7 _task_test7 1 /lib/dsp/modules/test7.o
>

(snip)

> I'm going to look at using the DSP with Octave (via oct files) for doing fast
> ffts, etc. I'd also like to see whether it might help with speeding up JPEG
> decoding, which leads me rather obliquely onto the IVA.
>
> I've tried searching for this, but all I seem to get are promo. pdfs about how
> it's included in various OMAPs, and how wonderful it is, but nothing about what
> it actually is. For example, is it like the DSP, where it runs its own kernel,
> or is it a chip with set functionality that would have a limited set of function
> calls, etc.? Is there some technical documentation available for it anywhere? I
> suppose this question may be better asked on the linux-omap-open-source mailing
> list as some people there have been/are working on a DSP-IVA task bridge (e.g.
> see http://komalshah.blogspot.com/), but I thought I'd tack it on here and see
> whether anyone has run across anything.

Nothing but the literature you've seen. Companies seem to love to
hoard information and charge a hefty entrance fee for a peek. Once
again, shooting from the hip I would imagine it would be a overlay on
top of the existing MCU core, much like MMX1 is/was. Sharing/reusing
registers would make for a smaller footprint in silicon, and the IVA
functions would remain quiescent until invoked by specific
instructions/mode changes. The tricky part (and likely why Nokia
hasn't touched it yet) would be cleanly running that type of code
without hurting performance for the rest of the "normal" code that
needed to be able to switch out of the "Uber-IVA" mode, save registers
and extra state information, and then get back to business once more
when the IVA-specific code comes up again in the task queue. That,
and the small detail of the GPL, since somehow both the kernel,
compiler, and applications that use the functionality would need to be
aware of the their part in how it functions. Give it a miss, unless
TI and so forth are willing to open up a bit.

Thanks for your continued efforts in the DSP hacking. The more we
know, the more fun we can with specific codecs and other projects,
although it sounds as if the latency in pushing the data back and
forth to the DSP can be a limiting factor.

Larry
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

S.G.Pickering at bath

May 11, 2007, 6:59 AM

Post #8 of 8 (2418 views)
Permalink

RE: DSP programming [In reply to]

Thanks for your thoughts about the IVA, over lunch I did some more googling and
found a couple of non-authoritative posts about it. Looks like it might be a
separate processor like the DSP, with its own kernel (not sure whether this is
changeable).

See:
http://linux.omap.com/pipermail/linux-omap-open-source/2007-April/009494.html
And:
http://www.learn4good.com/jobs/language/english/search_resumes/computer/macedoni
a/cv/108935/ (scroll down & search for "IVA")

Still no idea where these people got their information from. Interestingly, I'd
expected the Ti supplied kernel source to have more stuff related to the IVA in
it, but there's not much at all other than some power management and clock
setting code. I've not searched in it for the DSP, perhaps the kernel is
relatively bare in terms of these peripherals, leaving that up to whomever
decides to use it with Linux.

> Thanks for your continued efforts in the DSP hacking. The
> more we know, the more fun we can with specific codecs and
> other projects, although it sounds as if the latency in
> pushing the data back and forth to the DSP can be a limiting factor.

This is a good point and needs some testing. If the data are only sent one way
(e.g. sound data processed then output directly) then this is not a major issue,
depending on the rate at which it's processed vs. memory vs. transfer speed,
etc., but if it's bi-directional then I agree, it might not be very useful.

We'll have to test and see :)

Simon

_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com