Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#11281 - [New WMA Codecs] WMA Pro simulator playback

Attached to Project: Rockbox
Opened by MohamedTarek (mtarek16) - Sunday, 16 May 2010, 20:46 GMT+2
Last edited by MohamedTarek (mtarek16) - Tuesday, 27 July 2010, 11:49 GMT+2
Task Type Patches
Category Codecs
Status Closed
Assigned To No-one
Player Type All players
Severity Low
Priority Normal
Reported Version Release 3.4
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

This patch enables the playback of WMA Pro streams in the simulator, but it's still in an early phase. There's also some random clicking noise along with the output,
   wmapro.float_sim.v1.patch (17.5 KiB) 
 apps/codecs/libasf/asf.h                      |    3 
 apps/codecs/codecs.make                       |    3 
 apps/codecs/wmapro.c                          |  138 +++++++++++++++++++++++++-
 apps/codecs/libwmapro/SOURCES                 |    9 +
 apps/codecs/libwmapro/libavutil/mathematics.c |    8 -
 apps/codecs/libwmapro/libavutil/internal.h    |    8 -
 apps/codecs/libwmapro/libavutil/log.c         |    4 
 apps/codecs/libwmapro/libavutil/mathematics.h |    2 
 apps/codecs/libwmapro/fft.c                   |    4 
 apps/codecs/libwmapro/wmaprodec.c             |   39 +++++--
 apps/codecs/libwmapro/wmaprodec.h             |    6 +
 apps/codecs/libwmapro/libwmapro.make          |   18 +++
 apps/codecs/libwmapro/dsputil.h               |    2 
 apps/metadata/asf.c                           |   16 ++-
 14 files changed, 226 insertions(+), 34 deletions(-)

This task depends upon

Closed by  MohamedTarek (mtarek16)
Tuesday, 27 July 2010, 11:49 GMT+2
Reason for closing:  Accepted
Additional comments about closing:  last patch committed in r27402.
Comment by MohamedTarek (mtarek16) - Friday, 21 May 2010, 18:13 GMT+2
Regarding the noise in playback, it seems to be a simulator-specific problem.
I had test_codec produce a wav file from a wma pro sample. The output wav file played fine outside the simulator, but the noise was still there (in the wav file) in the simulator. I'll just ignore that for now.

The previous patch produced 16-bit samples. The current one produces 32-bit samples, and adds seeking too.
   wmapro.float.sim.v1.1.patch (17.6 KiB) 
 apps/codecs/codecs.make                       |    3 
 apps/codecs/wmapro.c                          |  156 +++++++++++++++++++++++++-
 apps/codecs/libwmapro/SOURCES                 |    9 +
 apps/codecs/libwmapro/libavutil/mathematics.c |    8 -
 apps/codecs/libwmapro/libavutil/internal.h    |    8 -
 apps/codecs/libwmapro/libavutil/log.c         |    4 
 apps/codecs/libwmapro/libavutil/mathematics.h |    2 
 apps/codecs/libwmapro/fft.c                   |    4 
 apps/codecs/libwmapro/wmaprodec.c             |   39 ++++--
 apps/codecs/libwmapro/wmaprodec.h             |    6 +
 apps/codecs/libwmapro/libwmapro.make          |   18 +++
 apps/codecs/libwmapro/dsputil.h               |    2 
 apps/metadata/asf.c                           |   16 +-
 13 files changed, 242 insertions(+), 33 deletions(-)

Comment by Andree Buschmann (Buschel) - Monday, 24 May 2010, 13:25 GMT+2
1) The patch doesn't build against r26246 on cygwin.
2) Is it possible that the random clicking noise is caused by sample overflow? E.g. a float samples >1.0 or <-1.0 will cause overflow.
2a) You could easily spot this in the wav-file. A simple way to check for this is to not scale by INT32_MAX but by e.g. ((1<<24)-1) to get a 8.24 representation. Additionally you'll need to configure the dsp settings accordingly. This way the dsp routines take care of saturation.
2b) If even saturated samples result in clicking noise, then try to reduce the scale in general and check whether the the output is fine then.
Comment by MohamedTarek (mtarek16) - Monday, 24 May 2010, 14:21 GMT+2
Regarding the samples overflow, in wmaprodec.c the float samples are clipped to be in the range [-1.0, 1.0[ so there should be no overflows. (and just to be safe, I reduced the range to check but nothing changed).
Before sending the patch, I tried reducing the scale factor but still nothing changed.

The thing is, when I checked the plot in something like Audacity, I didn't see saturated samples anywhere where I hear the noise.
I even applied a negative gain using audacity, and tried playing the file again in the sim, but again, nothing changed regarding that noise.

Here's part of the file I edited in audacity : http://filebin.ca/fhrnph/test.wav

The original file is the first one here : http://samples.mplayerhq.hu/A-codecs/WMA9/wmapro/

As to why it doesn't build, I sitll haven't checked. I'm currently preparing for my finals which start in ~1 week from now :( , so not sure when I'll be able to check it.
Comment by MohamedTarek (mtarek16) - Monday, 24 May 2010, 14:45 GMT+2
FWIW, I've also tried converting the same file in the previous post to wav with ffmpeg. Played the output wav file in the sim and got the same noise.
Comment by Andree Buschmann (Buschel) - Monday, 24 May 2010, 15:08 GMT+2
Ok, sounds like another issue then. Good luck for your exam!
Comment by MohamedTarek (mtarek16) - Friday, 25 June 2010, 01:48 GMT+2
This patch convert the MDCT windowing step to fixed point math. It's still very dirty with lots of experimental stuff, but functionally, it should be correct. There's an error in the audio output however that I still can't trace to something specific.
   wmapro_fixwinv1.patch (194.1 KiB) 
 apps/codecs/libwmapro/types.h        |   22 
 apps/codecs/libwmapro/wmapro_math.h  |   40 +
 apps/codecs/libwmapro/mdct_tables2.h | 1364 ++++++++++++++++++++++++++++++++++
 apps/codecs/libwmapro/mdct_tables.h  | 1372 +++++++++++++++++++++++++++++++++++
 apps/codecs/wmapro.c                 |    2 
 apps/codecs/libwmapro/wmaprodec.c    |   50 -
 6 files changed, 2827 insertions(+), 23 deletions(-)

Comment by MohamedTarek (mtarek16) - Friday, 25 June 2010, 12:42 GMT+2
Ok, I figured out the problem.
The point in code where the floating point coefficients are converted to fixed point was wrong. Now the sound quality is very good and plots show that the max error between the current decoder (with fixed point windowing) and that of ffmpeg's is 3.052*10^-5 which is good I think.
Comment by MohamedTarek (mtarek16) - Tuesday, 06 July 2010, 00:01 GMT+2
This patch converts imdct, windowing and inverse quantization and rescaling steps to fixed point maths.
With this patch, wmapro uses its own imdct not ours, because of different trig tables.
   wmap_fixed.v1.1.patch (228.8 KiB) 
 apps/codecs/wmapro.c                 |    2 
 apps/codecs/libwmapro/SOURCES        |    2 
 apps/codecs/libwmapro/types.h        |    8 
 apps/codecs/libwmapro/wmapro_mdct.c  |   51 
 apps/codecs/libwmapro/fft.c          |    6 
 apps/codecs/libwmapro/wmaprodec.c    |   89 
 apps/codecs/libwmapro/wmapro_mdct.h  |    8 
 apps/codecs/libwmapro/mdct_tables.c  | 3389 +++++++++++++++++++++++++++++++++++
 apps/codecs/libwmapro/README.rockbox |   14 
 apps/codecs/libwmapro/wmapro_math.h  |   46 
 apps/codecs/libwmapro/fft.h          |   10 
 apps/codecs/libwmapro/mdct_tables.h  |    9 
 apps/codecs/libwmapro/mdct.c         |    8 
 apps/codecs/libwmapro/quant.h        |   45 
 14 files changed, 3644 insertions(+), 43 deletions(-)

Comment by MohamedTarek (mtarek16) - Saturday, 10 July 2010, 12:03 GMT+2
This patch converts the whole decoder to fixed point (no multichannel yet though).
There's still some bug with it that I can't track down. I think - but still not sure - something goes wrong in the imdct step.
Once this is fixed I could proceed on removing the unneeded code and start testing on hardware.
EDIT : The code in this patch isn't pretty at all, it is still for testing purposes. You've been warned !
   wamp_fixed.v1.2.patch (27.4 KiB) 
 apps/codecs/codecs.make             |    4 
 apps/codecs/SOURCES                 |    1 
 apps/codecs/libwmapro/wmaprodata.h  |   49 +++++++++++
 apps/codecs/libwmapro/wmaprodec.c   |  150 +++++++++++++++++++++++++++++++-----
 apps/codecs/libwmapro/wmapro_math.h |    5 -
 apps/codecs/libwmapro/wma.c         |   58 +++++++++++++
 apps/codecs/libwmapro/wma.h         |    6 +
 7 files changed, 252 insertions(+), 21 deletions(-)

Comment by Dave Hooper (stripwax) - Monday, 12 July 2010, 11:22 GMT+2
Do you need to clip >= 1.0 rather than > 1.0 ? The fixed-point representation cannot represent exactly 1.0 (even though it can represent exactly -1.0)
Comment by MohamedTarek (mtarek16) - Monday, 12 July 2010, 11:55 GMT+2
Thanks for helping Dave, but that's not it. I discovered the source of the bug yesterday and fixed it, I'll clean up tonight to prepare for committing.
The problem was with the mdct, I shifted the trig table values up by 16 which made some values overflow (stupid mistake), so I split the shifts between the trig values and the input coefficients and now everything is good. Fixed point step finally over ! or almost over, since it's still not in svn.
Comment by Dave Hooper (stripwax) - Tuesday, 13 July 2010, 13:55 GMT+2
So thinking about this some more -- wouldn't this now enable using the codeclib mdct? i.e. with the inputs shifted the 'appropriate' amount (and if necessary the outputs also shifted, although not certain about that), the codeclib imdct should be functionally *identically* to the wmapro mdct right? Is the challenge then to determine what is the correct shift to use for the inputs? It seems like the trig values are shifted by 14 bits so that they don't overflow -- which (I think) is the same as saying that the trig values now fall into the range of -1 <= t < 1 in the s.31 representation, which (I think) is the same trig table as used by codeclib.
Comment by Dave Hooper (stripwax) - Tuesday, 13 July 2010, 14:17 GMT+2
.. although the sincos wmap table seems to contain lots of tables all contatenated together, and it looks like wmapro is making use of the 'scale' argument when it did its mdct_init . So, I think, we just need to prescale the input by that same scale amount, rather than scale the trig table? Or something like that ... ?
Comment by MohamedTarek (mtarek16) - Wednesday, 14 July 2010, 10:19 GMT+2
I tried that before my last commit. What I did was that I converted the scales in mdct_init to fixed point, and before passing the input buffer to the mdct (codeclib's in that case), I would scale the coefficients based on the mdct size, like mdct_init does, to avoid overflows, but it still overflowed. I'll look more into it later, I wanted to get the codec working first, so I consider this an optimisation/enhancement.

Loading...