Hi Brad
>> Right, well goodish news, the dsp sbc encoder appears to work. It can be
>> used with mplayer to play ~1s of audio, then it all goes quiet.
>
> this is how it was when trying the floating point version on an
> emulated fpu. There's no way it could keep up.
Ok, so the symptoms sound familiar, that's a good start.
>> though as I understood that the code could run in real-time on a 200MHz
>> StrongARM chip, I'd thought the DSP would be able to also run it without any
>> tweaks?
>
> the dsp is not going to perform well on general-purpose code. There
> are a few matrix ops that need to be rewritten first probably.
>
> sbc_analyze_{four,eight} are the main culprits. These have been
> optimized to combine & remove multiplications whenever unnecessary,
> but to preserve symmetry on a dsp you'll undo that to get it optimal.
Yes, ok. Is there, lurking around somewhere, a copy of the first code
that was written, before the various optimisations were put in? It
would be interesting/useful to look at something like that to see
where the DSP might be changed.
If not then fair enough, I'll have to work through the code and as you
say undo the optimisations before applying DSP-specific ones, etc.
>> Anyway, what I'm saying is that at first glance I can't really see a faster
>> way of transferring the data across (though I will do some testing to see
>> what the cold hard figures say), but if anyone spots a mistake or two in my
>> logic please pipe up.
>
> I'm not sure how this impacts you but the soft codec could benefit
> from zero copy. We'd need to change the internal representation to
> match host-endian stereo audio and only copy it if the incoming data
> is not in that format. There is a complication in that the codec has
> some state from previous encode calls, so we'd need to rework things
> so a buffer we refer to isn't changed by the client between calls.
Zero-copy could work if I used a shared memory buffer, but that would
mean I'd need to open the DSP device and map the shared memory buffer
somewhere earlier in the code, and be able to pass that buffer address
back to the code for it to use it.
In the meantime, I'll test just how long the bulk transfers take (I
did a quick cheat test by not calling sbc_encode() on the DSP side
(but accepting the data, and then passing it back) and just setting
len and encoded to the values I know the code produces. Unfortunately
the encoder stalls at the end of the stream (which doesn't help "time"
very much to get an accurate value). I need to have a fiddle with the
code and see what sbc_encode() returns when there's no/not enough data
to process to try to avoid the stall when I'm faking it.
Cheers,
Simon
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
