2011/9/30 Feng Wei <feng.wei(a)linaro.org>:
> 2011/9/30 Mans Rullgard <mans.rullgard(a)linaro.org>:
>> 2011/9/30 Feng Wei <feng.wei(a)linaro.org>:
>>> I rebuild the libav with neon enabled, and I got the new benchmark, as below
>>>
>>> time avconv -i SourceCode.dts -f s16le a.pcm
>>> panda -- 4.135s (53% better than non-neon version 6.320s)
>>> mx53 -- 19.054s (165% better than non-neon version 50.526s)
>>>
>>> So as mru said, dts is mostly neon optimized. Although it's not so
>>> reasonable on A8 cpu, I think we don't need to put it into next cycle.
>>
>> Which revision of libav did you use for these benchmarks? Did it include the
>> optimisation I added a couple of days ago (baf6b738)? With the latest version,
>> I get almost exactly the same speed on Beagle-xm and Panda. Could you share
>> your test file in case there's something special about it?
>
> although i got latest git version today including baf6b738, the
> results are same as my last version.
> I attach the dts file
With that file I get 2.3s on Beagle-xm, 2.2s on Panda, using latest libav git
built with Linaro gcc 4.5-2011.09.
--
Mans Rullgard / mru
Hi Alexander,
Based on the mails I have tried to capture the requirements in a
block diagram.Please let me know if there are any mistakes in the digram.
I wanted to add a few points regarding the final comparison block which
is being sought to be compared using Speech recognition.
I think the comparisons can very easily be done using a PSNR comparison
which will effectively do a comparison of two streams for
differences in the audio samples.This kind of measurements is quite
mature in audio codecs and can as well work here.
Speech recognition has its own sets of problem of training the
recognition engine and it is notoriously erroneous.This was my
observation while working
on a ASR engine.So,finally we may end up doing a testing of the sphiks
;) rather than the Panda audio .But,it is definitely worth a try.
Block Diagram
http://www.gliffy.com/publish/2944818/
Regards
Rony
-------- Original Message --------
Subject: Re: end-to-end audio testing (jacks)
Date: Tue, 27 Sep 2011 18:25:05 +0200
From: Alexander Sack <asac(a)linaro.org>
To: Kurt Taylor <kurt.taylor(a)linaro.org>
CC: linaro-multimedia(a)lists.linaro.org, David Zinman
<david.zinman(a)linaro.org>
On Tue, Sep 27, 2011 at 5:16 PM, Kurt Taylor <kurt.taylor(a)linaro.org
<mailto:kurt.taylor@linaro.org>> wrote:
On 27 September 2011 09:18, Alexander Sack <asac(a)linaro.org
<mailto:asac@linaro.org>> wrote:
Hi,
we are looking at landing more and more full stack test cases
for our automated board support status tracking efforts.
While for some hardware ports it's hard to test whether a port
really gets a proper signal etc, we feel for audio this might be
relatively straight forward: we got the idea that we could
connect a cable from jack out to jack in in the lab and then have
a testcase that plays something using aplay and checks that he
gets proper input/signal on the jack in.
This could be done on alsa level and later pa level (for ubuntu).
A more advanced idea that came up when discussing options was to
use opensource speech recognition like sphinx to even
go one step further and see if the output we produce yields
roughly the same input. For that we could play one or two words,
use speech recognition to parse it and check if the resulting
text is stable/expected.
What do you think?
These are really good ideas. I had started a discussion with Torez
several months ago about an automated test for audio. My idea at
the time was to use a sine wav at a particular frequency and use or
hack one of the tuner/freq analysis apps to detect the frequency. If
it was too garbled or distorted, it wouldnt recognize the frequency.
As you know, sound quality is very subjective and depends on the
cables, speakers, amp, etc. I like the speech recognition idea as
well, for the same reasons. It might actually be a better test of
the quality.
right. i think it would be hard to measure real audio quality, but if we
get speech recognition going we would at least know that the input was
similar enough to what we played.
I think some experiments with pocketsphinx would make sense to see how
easy that would be. I am happy to create a blueprint for the first
investigation steps for your backlog with a quick outline.
Would MMWG be able to take experimenting and implementing such
end-to-end audio test into their 11.10 work list?
I think this is a really good idea to explore. Could we also maybe
use camera and face recognition when we hack a pandaboard to do
that? Hm...
psssst ... i wanted to keep that idea back for a bit :).
--
Alexander Sack
Technical Director, Linaro Platform Teams
http://www.linaro.org | Open source software for ARM SoCs
http://twitter.com/#!/linaroorg <http://twitter.com/#%21/linaroorg> -
http://www.linaro.org/linaro-blog
Following tests are based on latest libav git. built with same
configurations. The result is even stranger than gst-ffmpeg with sync.
time avconv -i nfsroot2/bitstreams/720p/Source.Code.2011.BluRay.720p.DTS.x264-CHD.mkv
-t 0:1:0 -f s16le a.pcm
panda -- 8.345s
mx53 -- 54.678s
time avconv -i nfsroot2/bitstreams/720p/Source.Code.2011.BluRay.720p.DTS.x264-CHD.mkv
-t 0:1:0 -f s32le b.pcm
panda -- 9.419s
mx53 -- 63.294s
mru, how can I enable profile instruments in libav, any configuration options?
Why native gcc in linaro releases can't support neon instructions? I
think both above platforms support neon.
--
Wei.Feng (irc wei_feng)
Linaro Multimedia Team
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi,
we are looking at landing more and more full stack test cases for our
automated board support status tracking efforts.
While for some hardware ports it's hard to test whether a port really gets a
proper signal etc, we feel for audio this might be
relatively straight forward: we got the idea that we could connect a cable
from jack out to jack in in the lab and then have
a testcase that plays something using aplay and checks that he gets proper
input/signal on the jack in.
This could be done on alsa level and later pa level (for ubuntu).
A more advanced idea that came up when discussing options was to use
opensource speech recognition like sphinx to even
go one step further and see if the output we produce yields roughly the same
input. For that we could play one or two words,
use speech recognition to parse it and check if the resulting text is
stable/expected.
What do you think?
Would MMWG be able to take experimenting and implementing such end-to-end
audio test into their 11.10 work list?
Thanks for your support!
--
Alexander Sack
Technical Director, Linaro Platform Teams
http://www.linaro.org | Open source software for ARM SoCs
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi folks
I was just told that for any release tarballs, we should avoid a "+"
character in the tarball name. We should use "-" instead.
Please take note of this in future releases
thanks
--
Ilias Biris ilias.biris(a)linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs
I did some quick and dirty profiling of libpng decoding on a Beagle-xm.
This is the result with one image:
46.18% pngbench pngbench [.] inflate_fast
26.12% pngbench pngbench [.] png_read_filter_row
7.81% pngbench pngbench [.] inflate
5.65% pngbench pngbench [.] memcpy
4.26% pngbench pngbench [.] adler32
2.39% pngbench pngbench [.] crc32
1.78% pngbench [kernel.kallsyms] [k] __copy_to_user
1.76% pngbench [kernel.kallsyms] [k] __do_softirq
1.40% pngbench pngbench [.] inflate_table
1.02% pngbench [kernel.kallsyms] [k] __memzero
And another:
64.79% pngbench pngbench [.] inflate_fast
8.61% pngbench pngbench [.] memcpy
7.46% pngbench pngbench [.] adler32
5.10% pngbench pngbench [.] crc32
3.49% pngbench pngbench [.] inflate
3.16% pngbench [kernel.kallsyms] [k] __copy_to_user
1.33% pngbench [kernel.kallsyms] [k] __memzero
And a third:
47.00% pngbench pngbench [.] png_read_filter_row
28.52% pngbench pngbench [.] inflate_fast
5.12% pngbench pngbench [.] memcpy
4.23% pngbench pngbench [.] crc32
3.85% pngbench pngbench [.] adler32
1.60% pngbench [kernel.kallsyms] [k] __memzero
1.56% pngbench pngbench [.] inflate_table
1.50% pngbench [kernel.kallsyms] [k] __copy_to_user
1.38% pngbench [kernel.kallsyms] [k] __do_softirq
0.78% pngbench pngbench [.] inflate
Two of these are coded using a predictive filter resulting in
png_read_filter_row()
using a substantial amount of decoding time. Multiple filters are available,
thus the different amounts of time seen in that function above. When no such
filter is used, decoding time is dominated by zlib decompression.
Two checksum functions feature in these profiles. Adler32 is the checksum
used by zlib to verify data integrity, and crc32 is used by PNG.
Optimising the png_read_filter_row function in NEON is possible in
principle, the
effort of hooking this up in libpng might however be non-trivial. Assuming a
speedup of 4x for this function, the overall decoding performance
improvement would
be up to ~1.6x depending on the image. This should definitely be investigated
further.
A worryingly large amount of time is also spent in memcpy(). If some
of these calls
could be eliminated, a further 10% speed might be gained. This is likely to be
quite difficult.
Optimising zlib is of course also possible in theory, but is probably even more
difficult.
--
Mans Rullgard / mru
