WMA again

[Marsdaddy]

Here is an update, as promised!

I submitted a version of "libwma" to the tracker on Saturday and it was suggested that rather than integrate straightaway into the rockbox codec architecture, I should write a plugin to test the decoder for accuracy and speed.

Well, I've now written a "wma2wav" plugin, which is working on my simulator build.

Next step is to try it on a real device (iRiver H340) to see if it's up to the job. Listening to the WAV output I think it's a little "rough", I need to do something a bit more scientific with the output.

When I have wma2wav working and have more faith in the decoder, I shall make a patch of it.

And that is the end of the news.

[saratoga]

Awesome news!

Assuming you can get your iRiver to record the PCM samples, you could compare the output to WMP.  Do you have matlab?  You could pretty easily use the wavread() command on your output and WMP's and then go sample by sample to see how close you are.  I doubt you'll be sample exact since theres fp involved in the WMP decoder most likely, but assuming you're within a bit or two, I doubt anyone will mind

Edit:  new = news

[MU4L]

Great work Marsdaddy - look forward to the patch !!!

[Mr. Brownstone]

Fantastic news! Keep up the good work, we all appreciate it!

[Marsdaddy]

Further update for those awaiting this!

I have completed the plugin WMA decoder and have been banging my head against the wall for the last few days because although the code compiles and runs fine in the uisimulator, it won't compile for my platform, the iRiver H340. For the technically minded, it causes an internal compiler error "insn does not satisfy its constraints".

I have been attempting to come up with test code that exhibits the problem but of course it does not show when I isolate the code. I will continue to rework/reorder the code until I get it to generate correctly.

Wish me luck 

[Bagder]

If you just produce a package/patch with what you have that shows the problem, I'm sure there are several people around that can help you.

Cooperation is what makes open source different you know!

[Mr. Brownstone]

Good luck and excellent work!

But here's a suggestion: Why not show your code to the other ROCKbox devs here? They already have a great deal of experience working with the H300's and may be able to show you where you're going wrong, and will speed up your learning process and development time.

[linuxstb]

Further update for those awaiting this!

I have completed the plugin WMA decoder and have been banging my head against the wall for the last few days because although the code compiles and runs fine in the uisimulator, it won't compile for my platform, the iRiver H340. For the technically minded, it causes an internal compiler error "insn does not satisfy its constraints".

I have been attempting to come up with test code that exhibits the problem but of course it does not show when I isolate the code. I will continue to rework/reorder the code until I get it to generate correctly.

Wish me luck 

I've came up against these problems with porting the AAC codec - it's due to bugs in the m68k version of gcc.

One thing that worked was to ensure that the signedness of variables was consistent - i.e. removing comparisons between signed and unsigned variables seems to tickle gcc into submission.

Otherwise, just try randomly changing your code...

But as Daniel said, if you post a package of your source so far, then others would be happy to help.

[Marsdaddy]

I've came up against these problems with porting the AAC codec - it's due to bugs in the m68k version of gcc.

One thing that worked was to ensure that the signedness of variables was consistent - i.e. removing comparisons between signed and unsigned variables seems to tickle gcc into submission.

Thanks for this - I've made some modifications and it's got me past the original problem onto some more constraints violations. Thanks again for the suggestion 

[MU4L]

Just wondering if there was any more news on the progression front, Marsdaddy  ?




Hope everything's going well,


MU4L

[Marsdaddy]

Just wondering if there was any more news on the progression front, Marsdaddy  ?

Hope everything's going well,

Yes everything is going well but slowly... I was not expecting that the compiler used for the iRiver would have serious bugs in it! Anyway - I've got a plugin that compiles and runs fine in the simulator but barfs and dies on the H300 -- I am making progress but it's taking longer than I hoped.

So good news of sorts. I'll keep you posted - and the help I've had from the rockbox community has been invaluable 

[c0rrupted]

hell yea!!!. i only found out about rockbox a week ago and was dissapointed that it didnt support wma. alot of my collection is in mp3 but i have about 10 albums that are all wma and to convert from wma to mp3 i wouldnt think would be a good idea so keep up the good work m8

[Marsdaddy]

Another update for all those wondering where this has got to...

Today I decoded a WMA file on my H300 via a plugin I've written

That's the good news, two current issues: -

1) The decoder is not accurate enough - I sort of knew this but wanted to carry on with getting the WMA decoder working in the simulator and H300 first. I have a plan for tackling this as I can debug another WMA decoder etc. etc.

2) The decoder is sllllloooooowwwww... too slow. Good news is there are a number of places in the code that optimisations can be made.

I will tackle issue (1) first then optimise the fixed version

As always, when there is something to tell you I will post here 

[MU4L]

Brilliant news Marsdaddy, and good to see you getting on so well.


I look forward to hearing more news from you  .



MU4L

[preglow]

1) The decoder is not accurate enough - I sort of knew this but wanted to carry on with getting the WMA decoder working in the simulator and H300 first. I have a plan for tackling this as I can debug another WMA decoder etc. etc.

When I had a look at the patch, I noticed you only seem to use 32 bit multiplies everywhere. Might the precision problems be related to this? We usually use 64 bit muls pretty much everywhere we can.

2) The decoder is sllllloooooowwwww... too slow. Good news is there are a number of places in the code that optimisations can be made.

No surprise there. Almost all our codecs had to have quite some optimising before running well. How slow are we talking? I bet there are some people (me included) that'd love to help you in optimising it, so pretty please, aim to have it commited before you start working too much on this on your own
Nice work!