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
--
To UNSUBSCRIBE, email to debian-arm-re
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?
>
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
Co
Am Tue, 4 Mar 2014 16:25:17 -0300
schrieb Felipe Sateler :
> >> #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 2:2
On Tue, Mar 4, 2014 at 2:26 PM, Thomas Orgis wrote:
> Am Tue, 4 Mar 2014 11:10:25 -0300
> schrieb Felipe Sateler :
>
>> #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
Am Tue, 4 Mar 2014 11:10:25 -0300
schrieb Felipe Sateler :
> #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 float output from
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 t
On Mon, Mar 3, 2014 at 11:59 PM, peter green 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:
==
felipe@felipepi:mp
Am Tue, 4 Mar 2014 11:49:45 +0100
schrieb Thomas Orgis :
> 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
signature.asc
Descript
Am Tue, 04 Mar 2014 02:59:44 +
schrieb peter green :
> 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 rounding for small
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
whi
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_fp
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 12:02:40PM +0100, Thomas Orgis wrote:
> Am Sat, 01 Mar 2014 01:00:02 +0900
> schrieb Taihei Momma :
>
> > 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
On Sun, Mar 2, 2014 at 6:02 AM, Thomas Orgis wrote:
> Am Sat, 01 Mar 2014 01:00:02 +0900
> schrieb Taihei Momma :
>
>> 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 her
Am Sat, 01 Mar 2014 01:00:02 +0900
schrieb Taihei Momma :
> 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,
http://mpg123.org/snapsh
Am Sat, 1 Mar 2014 09:56:46 +0100
schrieb Thomas Orgis :
> 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 1.18.1 after con
Am Sat, 01 Mar 2014 01:00:02 +0900
schrieb Taihei Momma :
> 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
> disti
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 wo
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.
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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
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 instr
Am Tue, 25 Feb 2014 11:20:06 -0500
schrieb "Lennart Sorensen" :
> 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 :
> >
> > > #0 0xb6fb9332 in INT123_dct64_neon () at dct64_neon.S:48
> > > ^
> > > not a
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 :
>
> > #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 committe
Am Tue, 25 Feb 2014 17:37:41 +0900
schrieb Taihei Momma :
> #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,
http://mpg123.
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:
http://www.mpg123.de/
Am Mon, 24 Feb 2014 12:27:36 -0500
schrieb "Lennart Sorensen" :
> 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 make sense. I (and actual
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" :
>
> > 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 config
Am Fri, 21 Feb 2014 11:25:12 -0500
schrieb "Lennart Sorensen" :
> 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 NEON instructions
> being i
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'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 tow
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 hopefu
> >> > 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 curren
On 2014-02-17, Steve McIntyre wrote:
> Yes, you can do that - build several copies of the library and use the
> hwcaps / auxv approach to pick the best one for the hardware at link
> time.
>
>>NEON detection may come... but if we have linker selection, that would
>>be covered right now.
>
> Yup.
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 :
>
>> 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 a
Am Mon, 17 Feb 2014 10:00:48 +0200
schrieb Riku Voipio :
> 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 solution is for t
36 matches
Mail list logo
