Riku Voipio wrote:
I think nofpu would good for raspian. Any lost audio quality would
unnoticable on the Rasberry's analog audio output ;)
Peter, what's the recommended way to recognize raspbian in debian/rules
?
dpkg-vendor --derives-from raspbian
On Tue, Mar 04, 2014 at 11:49:45AM +0100, Thomas Orgis wrote:
In any case ... Riku: Care to run timings of MAD on your
configurations? I'm interested in how fast it is producing that 24 bit
output on limited CPUs.
time madplay -d -o null: convergence_-_points_of_view/*.mp3 /dev/null
Cortex
On Tue, Mar 04, 2014 at 02:59:44AM +, peter green wrote:
On Sun, Mar 02, 2014 at 09:06:44AM -0500, Reinhard Tartler wrote:
That sounds like if the mpg123 package should use:
on armel: --with-cpu=arm_nofpu
on armhf: --with-cpu=arm_fpu
Does this make sense to everybody?
Seems sane to
Am Tue, 04 Mar 2014 02:59:44 +
schrieb peter green plugw...@p10link.net:
Is there any quality
difference from using a fpu vs nonfpu decoder?
Technically, there is. See those numbers for generic fpu and non-fpu
code with and without --enable-int-quality given to configure (enables
better
Am Tue, 4 Mar 2014 11:49:45 +0100
schrieb Thomas Orgis thomas-fo...@orgis.org:
sh$ time -d -o null convergence_-_points_of_view/*.mp3
That should be
sh$ time madplay -d -o null: convergence_-_points_of_view/*.mp3
... as you may have guessed (notice the added :).
Alrighty then,
Thomas
On Mon, Mar 3, 2014 at 11:59 PM, peter green plugw...@p10link.net wrote:
wonder what we should use on raspbian? I haven't tested on a Pi yet but it
seems that on all tests i've seen so-far the generic fpu code is quite a bit
slower than the arm nofpu code.
Indeed, it seems to be:
==
On Tue, Mar 04, 2014 at 02:59:44AM +, peter green wrote:
Seems sane to me. armv7 devices without neon are relatively uncommon
so while it's important that they are supported it's IMO not vitally
important to squeeze out every last drop of performance from them.
I don't agree. At least the
Am Tue, 4 Mar 2014 11:10:25 -0300
schrieb Felipe Sateler fsate...@debian.org:
#decodert_s16/s t_f32/s
ARM 86.26 90.66
generic 102.80 100.06
generic_dither 121.10 100.84
Yes, a difference, but aguably a lot less than comparing VPU code to
NEON. With the feature to produce
On Tue, Mar 4, 2014 at 2:26 PM, Thomas Orgis thomas-fo...@orgis.org wrote:
Am Tue, 4 Mar 2014 11:10:25 -0300
schrieb Felipe Sateler fsate...@debian.org:
#decodert_s16/s t_f32/s
ARM 86.26 90.66
generic 102.80 100.06
generic_dither 121.10 100.84
Yes, a difference, but
Am Tue, 4 Mar 2014 16:25:17 -0300
schrieb Felipe Sateler fsate...@debian.org:
#decodert_s16/s t_f32/s
ARM 86.26 90.66
generic 102.80 100.06
generic_dither 121.10 100.84
madplay -d -o null: convergence_-_points_of_view/*.mp3 /dev/null
130.22s user 1.88s system 93% cpu
On Sun, Mar 02, 2014 at 12:02:40PM +0100, Thomas Orgis wrote:
Am Sat, 01 Mar 2014 01:00:02 +0900
schrieb Taihei Momma t...@mac.com:
OK, after some investigation with armhf cross environment and qemu, finally
the current mpg123 svn (r3517) should work
After Tahei didn't stop at this
On Sun, Mar 02, 2014 at 12:02:40PM +0100, Thomas Orgis wrote:
After Tahei didn't stop at this (big thanks from here!), we got a new
snapshot,
http://mpg123.org/snapshot/mpg123-20140302115523.tar.bz2 ,
that will hopefully become mpg123 1.19.0 soon (not 1.18.x
because of feature
On Sun, Mar 02, 2014 at 09:06:44AM -0500, Reinhard Tartler wrote:
That sounds like if the mpg123 package should use:
on armel: --with-cpu=arm_nofpu
on armhf: --with-cpu=arm_fpu
Does this make sense to everybody?
I think so. armhf's current debian rules automatically picked arm_fpu
with
On Sun, Mar 02, 2014 at 09:06:44AM -0500, Reinhard Tartler wrote:
That sounds like if the mpg123 package should use:
on armel: --with-cpu=arm_nofpu
on armhf: --with-cpu=arm_fpu
Does this make sense to everybody?
Seems sane to me. armv7 devices without neon are relatively uncommon so
Am Sat, 01 Mar 2014 01:00:02 +0900
schrieb Taihei Momma t...@mac.com:
OK, after some investigation with armhf cross environment and qemu, finally
the current mpg123 svn (r3517) should work
After Tahei didn't stop at this (big thanks from here!), we got a new
snapshot,
On Sun, Mar 2, 2014 at 6:02 AM, Thomas Orgis thomas-fo...@orgis.org wrote:
Am Sat, 01 Mar 2014 01:00:02 +0900
schrieb Taihei Momma t...@mac.com:
OK, after some investigation with armhf cross environment and qemu, finally
the current mpg123 svn (r3517) should work
After Tahei didn't stop at
Am Sat, 01 Mar 2014 01:00:02 +0900
schrieb Taihei Momma t...@mac.com:
OK, after some investigation with armhf cross environment and qemu, finally
the current mpg123 svn (r3517) should work (including arm_nofpu decoder).
The point is .type directive. Without this directive, a linker doesn't
Am Sat, 1 Mar 2014 09:56:46 +0100
schrieb Thomas Orgis thomas-fo...@orgis.org:
Great! So, folks, please check that
http://mpg123.de/snapshot/mpg123-2014030100.tar.bz2
does the trick with all decoders now. Performance numbers from the
benchmark script would be nice. I'll release
OK, after some investigation with armhf cross environment and qemu, finally the
current mpg123 svn (r3517) should work (including arm_nofpu decoder).
The point is .type directive. Without this directive, a linker doesn't
distinguish arm functions from thumb functions, and interworking doesn't
Am Mon, 24 Feb 2014 12:27:36 -0500
schrieb Lennart Sorensen lsore...@csclub.uwaterloo.ca:
Any help from this:
Program received signal SIGILL, Illegal instruction.
0xb6fb9332 in INT123_dct64_neon () at dct64_neon.S:48
48 vpush {q4-q7}
What the ... ? This does not
Wait, code alignment issue?
#0 0xb6fb9332 in INT123_dct64_neon () at dct64_neon.S:48
^
not a multiple of 4.
I've just committed a fix to mpg123 repository to align the function by 4
bytes. I supposed this was fixed before, but actually dct64 part was omitted:
Am Tue, 25 Feb 2014 17:37:41 +0900
schrieb Taihei Momma t...@mac.com:
#0 0xb6fb9332 in INT123_dct64_neon () at dct64_neon.S:48
^
not a multiple of 4.
Oh, d'oh! It could be that simple.
I've just committed a fix to mpg123 repository
I generated a new snapshot,
On Tue, Feb 25, 2014 at 11:18:50AM +0100, Thomas Orgis wrote:
Am Tue, 25 Feb 2014 17:37:41 +0900
schrieb Taihei Momma t...@mac.com:
#0 0xb6fb9332 in INT123_dct64_neon () at dct64_neon.S:48
^
not a multiple of 4.
Oh, d'oh! It could be that simple.
I've just committed
Am Tue, 25 Feb 2014 11:20:06 -0500
schrieb Lennart Sorensen lsore...@csclub.uwaterloo.ca:
On Tue, Feb 25, 2014 at 11:18:50AM +0100, Thomas Orgis wrote:
Am Tue, 25 Feb 2014 17:37:41 +0900
schrieb Taihei Momma t...@mac.com:
#0 0xb6fb9332 in INT123_dct64_neon () at dct64_neon.S:48
On 2014/02/26, at 1:44, Thomas Orgis wrote:
That address didn't change.
Well, the function itself is properly aligned (so my fix didn't take effect
anyway).
0xb6fb9330 +0: vpush {d8-d15}
0xb6fb9334 +4: sub r3, pc, #140; 0x8c
But the processor decoded the first instruction
On Wed, Feb 26, 2014 at 01:59:12AM +0900, Taihei Momma wrote:
On 2014/02/26, at 1:44, Thomas Orgis wrote:
That address didn't change.
Well, the function itself is properly aligned (so my fix didn't take effect
anyway).
0xb6fb9330 +0: vpush {d8-d15}
0xb6fb9334 +4: sub
Taihei Momma wrote:
But the processor decoded the first instruction as 2-byte (thumb?),
Note that debian armhf builds C code in thumb2 mode by default.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
On Sat, Feb 22, 2014 at 10:05:35AM +0100, Thomas Orgis wrote:
Am Fri, 21 Feb 2014 11:25:12 -0500
schrieb Lennart Sorensen lsore...@csclub.uwaterloo.ca:
Testing with the neon build I get a return code of 4, and it seems to
be failing to run. It was a pain to even get it to compile. Using
Am Fri, 21 Feb 2014 11:25:12 -0500
schrieb Lennart Sorensen lsore...@csclub.uwaterloo.ca:
Testing with the neon build I get a return code of 4, and it seems to
be failing to run. It was a pain to even get it to compile. Using just
the configure option, the assembler complained about the
On Fri, Feb 21, 2014 at 01:29:40AM +, peter green wrote:
Thomas Orgis wrote:
So, I got conversion to float implemented now and tested with the
generic_nofpu decoder on x86-64. It _should_ of course work with ARM,
too;-) If you'd like to check the current snapshot of mpg123,
I see. In that case, I'll have to leave the package as it until
something along those lines is implemented.
So, I got conversion to float implemented now and tested with the
generic_nofpu decoder on x86-64. It _should_ of course work with ARM,
too;-) If you'd like to check the current
Thomas Orgis wrote:
So, I got conversion to float implemented now and tested with the
generic_nofpu decoder on x86-64. It _should_ of course work with ARM,
too;-) If you'd like to check the current snapshot of mpg123,
http://mpg123.org/snapshot/mpg123-20140220132548.tar.bz2 ,
you
I'm adding the mpg123 assembly guru to the CC list, as I imagine he
would be interested in why his ARM NEON code doesn't work on a Cortex
A8 chip here. Needless to say, it worked before (on other systems).
Also, the precision of the arm_nofpu code does not look right. This
topic is now shifting
Am Mon, 17 Feb 2014 10:00:48 +0200
schrieb Riku Voipio riku.voi...@iki.fi:
Thanks Peter for explaining, this was how I ended up the suggestion
in the bug.
I see. In that case, I'll have to leave the package as it until
something along those lines is implemented.
Yes. The ideal
On Mon, Feb 17, 2014 at 11:43:16AM +0100, Thomas Orgis wrote:
Am Mon, 17 Feb 2014 10:00:48 +0200
schrieb Riku Voipio riku.voi...@iki.fi:
Thanks Peter for explaining, this was how I ended up the suggestion
in the bug.
I see. In that case, I'll have to leave the package as it until
Dear ARM porters,
Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738981
for full context. I've uploaded a patch proposed by Riku that AFAIUI
makes mpg123 really slow on all arm targets, while unbreaking it on
some others.
As one of the maintainers of the mpg123 without familiarity
On Sun, Feb 16, 2014 at 6:37 PM, peter green plugw...@p10link.net wrote:
Reinhard Tartler wrote:
Dear ARM porters,
Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738981
for full context. I've uploaded a patch proposed by Riku that AFAIUI
makes mpg123 really slow on all arm
Reinhard Tartler wrote:
With this explanation, I think it would help a lot to all armhf users
if the following line was restricted to the armel port:
http://anonscm.debian.org/gitweb/?p=pkg-multimedia/mpg123.git;a=blob;f=debian/rules;h=afb018502621352914e757338a2dace6b65522cb;hb=HEAD#l25
Umm
On Sun, Feb 16, 2014 at 7:28 PM, peter green plugw...@p10link.net wrote:
Reinhard Tartler wrote:
I mean line 55
I've just looked at ./configure --help and AIUI there are four possible
values of --with-cpu for arm systems
--with-cpu=generic_fpu Use generic processor code with floating
39 matches
Mail list logo
