[maemo-developers] DSP SBC encoder update

[From: Faheem Pervez]

Hi,

Glad you got it working, will grab a copy when I go home :)

Just some notes:
I found that patch I mentioned:
http://pastebin.com/m34ed3cd3

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.)

Using this snippet of code in the installer sh will automatically relaunch
the script as root if you are not root:
http://www.internettablettalk.com/forums/showpost.php?p=122754&postcount=5


Cheers,
Faheem


On Mon, Jul 7, 2008 at 11:43 AM, Simon Pickering <S.G.Pickering at bath.ac.uk>
wrote:

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