Hi,<br><br>Glad you got it working, will grab a copy when I go home :)<br><br>Just some notes:<br>I found that patch I mentioned:<br><a href="http://pastebin.com/m34ed3cd3">http://pastebin.com/m34ed3cd3</a><br><br>It's supposidly adds sysfs interface for modding the dsp speed. If that fails, a modification to n800-dvfs.c will work :) (I think I've got a kernel stashed away with DSP/CPU at 133/400.)<br>
<br>Using this snippet of code in the installer sh will automatically relaunch the script as root if you are not root:<br><a href="http://www.internettablettalk.com/forums/showpost.php?p=122754&postcount=5">http://www.internettablettalk.com/forums/showpost.php?p=122754&postcount=5</a><br>
<br><br>Cheers,<br>Faheem<br><br><br><div class="gmail_quote">On Mon, Jul 7, 2008 at 11:43 AM, Simon Pickering <<a href="mailto:S.G.Pickering@bath.ac.uk">S.G.Pickering@bath.ac.uk</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi all,<br>
<br>
I'm happy to say I've got the DSP task working for more than 4s now, in fact<br>
it even runs all the way to the end of the song, as expected ;).<br>
<br>
You can download version 1.0.0 from here:<br>
<a href="https://garage.maemo.org/projects/dsp-sbc/" target="_blank">https://garage.maemo.org/projects/dsp-sbc/</a>. This is for Diablo only.<br>
<br>
This consists of a tarball containing the DSP task and command file, a<br>
tweaked Bluez-utils which can use said DSP task for SBC encoding (so it will<br>
just work with mplayer and the like) and an installation script which writes<br>
some config data about the new task to the DSP dynamic loader conf file and<br>
then extracts the tarball, installs the deb and tells you to reboot.<br>
<br>
[Note to would-be DSP hackers: rather than rebooting, you can just run<br>
"dsp_dld" in the terminal to restart the loader daemon, but make sure you've<br>
made a symlink from /lib/dsp/dsp_dld_avs.conf -> /lib/dsp/dsp_dld.conf as<br>
this is where it expects to find the conf file.]<br>
<br>
If you want to go back to software encoding, rename the sbcenc.o file (in<br>
/lib/dsp/modules) and it will automatically fall back to the original<br>
software method (it falls back whenever the DSP fails, and renaming the task<br>
will cause it to fail). I've not checked to see if the fallback method is as<br>
quick as the original code, I'd be interested to know though if anyone is<br>
bored. I should add some logic using an env var or similar to switch method<br>
- anyone have some example code I could use?<br>
<br>
You still need to enable a2dp with either johnx's a2dp deb which can be<br>
found here: <a href="http://www.internettablettalk.com/forums/showthread.php?t=13468" target="_blank">http://www.internettablettalk.com/forums/showthread.php?t=13468</a><br>
or manually (use the deb, far easier).<br>
<br>
I should add that running DSP tasks will move the CPU frequency to 330MHz,<br>
so this is probably not the answer to everyone's prayers with regard to<br>
freeing the CPU to do Xvid decoding or the like. There is a kernel patch to<br>
not force the CPU to 330MHz (the DSP runs slower) and I'll do some testing<br>
to see if the DSP task can run in real-time at the lower DSP clock speed.<br>
Then it will be significantly more useful. In the meantime, it may or may<br>
not use less power this way, please let me know if you do any testing.<br>
<br>
<br>
<br>
Next bit is for those interested in the gory details:<br>
<br>
This is pretty much the same code I had running a week ago or thereabouts,<br>
and it was only encoding ~4s of audio in real-time (using bulk transfers &<br>
ioctls for sync). I tested the SW encoder and it would encode a test file<br>
more slowly than the DSP method but would output more seconds worth of audio<br>
when testing with mplayer, which made me wonder if the DSP was just cursed<br>
(or perhaps something to do with the CPU speed being set to 330MHz when the<br>
DSP is running...). The released code is from my mk2 branch:<br>
<a href="https://garage.maemo.org/plugins/scmsvn/viewcvs.php/mk2/?root=dsp-sbc" target="_blank">https://garage.maemo.org/plugins/scmsvn/viewcvs.php/mk2/?root=dsp-sbc</a><br>
<br>
The change which has allowed it to encode an entire song rather than just a<br>
few seconds was to move the input and output buffers from SDRAM (OMAP main<br>
memory) to SRAM (DSP fast single access memory). There are probably other<br>
things which would benefit from being moved, the sbc->priv data (or parts<br>
thereof) for one. This structure is pretty big so I allocated it in SDRAM,<br>
but at least parts of it might be better off in faster local memory. This is<br>
something to look at.<br>
<br>
I tested the speed of the bulk transfers (29s au file, took ~20s to encode<br>
with the DSP and ~9s to just transfer the data), which are pretty slow as<br>
you can see. I then decided to convert the task to use shared memory and<br>
some polling and sleeping to synchronise (mk4 branch:<br>
<a href="https://garage.maemo.org/plugins/scmsvn/viewcvs.php/mk4/?root=dsp-sbc" target="_blank">https://garage.maemo.org/plugins/scmsvn/viewcvs.php/mk4/?root=dsp-sbc</a>). The<br>
mk4 code takes absolutely forever to run though, the same test file which<br>
takes ~20s with the bulk transfer method (mk2) takes ~45s using shared<br>
memory. Unfortunately there appear to be no clocks available in the DSP<br>
kernel (which makes benchmarking code quite tricky) and also means you can't<br>
sleep() between polling memory.<br>
<br>
So the DSP task sits in a tight polling loop (bad!) and the ARM sleeps for<br>
1us and then polls the shared memory. Anyway, there's something not right<br>
and I'm not sure what it might be (the DSP manages ~650 loops before the ARM<br>
presents it with input data), the DSP then processes and the ARM sleeps for<br>
1 loop (1us) before the DSP gives it back the encoded data, and so on. This<br>
is not a good method for the task to use, but I am interested to know why<br>
it's so slow, so may do some more work on it eventually.<br>
<br>
Talking about a lack of clocks, the mk3 branch was my attempt to rewrite the<br>
sbc conversion fns using DSP intrinsics, dual MACs, and the like. It doesn't<br>
produce the correct output data (probably some issue with my Q15 arithmetic,<br>
this was only the first hack at the code) but also didn't improve the speed<br>
of the code (and with no clock fns it's hard to tell where the bottleneck<br>
is) so I'm leaving it alone for the time being.<br>
<br>
Last but not least, even when running at 165MHz (or whatever the<br>
conservative governor produces) the sw fall back code doesn't produce any<br>
error messages (when playing through mplayer for example - no audio output<br>
either I hasten to add). The DSP code did produce errors before the move<br>
from SDRAM->SRAM, namely the following:<br>
<br>
alsa-play: write error: Broken pipe<br>
alsa-play: trying to reset soundcard<br>
<br>
I'm curious to know what the difference is, and if it means I've not<br>
implemented some fn that I should have. Any ideas?<br>
<br>
Sorry for the typically long and rambling email, I'm sure there are things<br>
I've missed out, please ask :)<br>
<br>
Cheers,<br>
<br>
<br>
Simon<br>
<br>
<br>
_______________________________________________<br>
maemo-developers mailing list<br>
<a href="mailto:maemo-developers@maemo.org">maemo-developers@maemo.org</a><br>
<a href="https://lists.maemo.org/mailman/listinfo/maemo-developers" target="_blank">https://lists.maemo.org/mailman/listinfo/maemo-developers</a><br>
</blockquote></div><br>