Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Codecs
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Uchida - 2009-07-12
Last edited by Uchida - 2010-03-17

FS#10432 - Add Yamaha SMAF codec

Yamaha SMAF codec adds.

SMAF (.mmf extension file) is used as the format of the music file for the cellular phone.

This codec supports only wave data (ADPCM and PCM).
It does not support MIDI, picture, and movie.

It is necessary to apply patchs of  FS#10422 ,  FS#10423 ,  FS#10424 .

Closed by  Uchida
2010-03-17 12:28
Reason for closing:  Accepted
Additional comments about closing:  

new smaf codec commits and manual updates.

this patch will not apply either on the latest svn code at time of writing r. 21873

please apply the patch of  FS#10422 ,  FS#10423 ,  FS#10424 , and  FS#10425 . And after this task’s patch file applies.
When SMAF codec build failure still, please tell me the build environment.

Hi.
I wasn’t able to apply fs # 10424 directly after fs#10423. For some reason though I was able to apply it after I applied fs #10425.

However, I have now applied all the patches that this patch depends on, and it still won’t apply.
I also can’t apply fs #10433.
So the patches of yours that won’t apply are fs#10432 and fs #10433.
I am running a cygwin build environment.

It is very mysterious.
In my build environment, all patches can be normally applied.

I operate the follwoing:
$ cd rockbox (~/rockbox is stored Rockbox souces)
$ patch -p1 < ../rb_aiff_wav.patch ( FS#10422 )
$ patch -p1 < ../rb_ieee_float.patch ( FS#10423 )
$ patch -p1 < ../rb_adpcms.patch ( FS#10424 )
$ patch -p1 < ../rb_ima_adpcms.patch ( FS#10425 )
$ patch -p1 < ../rb_smaf.patch ( FS#10432 )

My build environment
OS

   Linux
   Windows + Cygwin

Source

  r21903


Hi. Just a thought, could you please make me a combined dif of all the patches, so that all I have to do is apply that one diff file? maybe that will apply for me. I tried removing all the individual patches and applying again from scratch, but again those two patches will not apply.

I send the patch which combined all patches ( FS#10422  -  FS#10425 , and  FS#10432 ).

Hi. sorry for not testing your combined diffs, I have been away in ireland for the past week.
I have just tried to apply them, and with the combined dif for this task, I am getting a lot of errors saying the files already exist. I assume this is because they were created by the other diff? is it possible for you to simply put up a diff of all your codecs to date that will apply without any problems? as at the moment I seem to be getting problems when I try to apply this combined diff.
I would simply like to be able to apply all your codec patches to date in one go.

OK, both diffs seem to apply fine individually, I just can’t seem to apply one on top of the other. I guess that’s because both try to create files that the first applied one already creates. I guess that whatever the problem was with the individual patch files must be gone with these combined diffs. I wonder what was causing the original problem.

I send new patch.

changes
- sync r24691
- sync new  FS#10424 ,  FS#10425  patch

Please apply new  FS#10424  and  FS#10425  patch before applying this patch.

fml2 commented on 2010-02-24 11:51

I think the task can be closed only after the manual has been updated as well. Please document the new supported audio file type in the manual.

And one more thing: it’s good to say in what SVN revision the patch has been committed.

One other suggestion:

static unsigned char smafbuf[1024];

The metadata parser are loaded all the time, unlike the codecs (which load only when needed). This is a very large buffer to leave allocated all the time in rockbox even if no SMAF files are used. Putting this on the stack would allow the memory to be freed after the parser is done.

I’ve moved that buffer - I probably misunderstood, but it seems local to one function anyway. There has still been a big binary size increase (~2K) which ought to be investigated further.

SMAF header parsing process changes;

  1. title/artist/composer are stored id3v2buf instead of id3v1buf.
  2. I corrected that there is no problem even if audio data is at which position from the head.

Please verify it.

I change my new patch more.
Because the increase size of the firmware after it applies is large (about + 1k), is committing impossible?
I check and change logics more (sigh…).

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing