Rockbox

The error comes from the decoder but current ffmpeg can decode it so it's possible it's some bug fixed in ffmpeg since we imported the codec. Otoh i'm not sure how we handle multichannel in flac.

With the attached patch the file decodes, but I am not sure if the correct two channels are chosen from the 5.1-signal.

Edit: http://flac.sourceforge.net/format.html#frame says that the first two channels in a multichannel set (2-6 channels) are the left and right channel. Therefor this patch should correctly extract the left and right channel out of the 5.1 signal.

On my device (fuze+) this patch leads to (with backtrace patch, and coming from an mp3 dynamic playlist, different compression were tested):
Data abort at 6006BB10
FSR 0x8
(domain 0, fault 8)
address 0x65E85284
backtrace start
pc: 0x6006BB10
sp: 0x60000118
backtrace end

or:

Data abort at 6006BB10
FSR 0x8
(domain 0, fault 8)
address 0x63E74578
backtrace start
pc: 0x63E74578
sp: 0x00005280
backtrace end
this might be related to ( FS#12429 )
Both on test file as on other file of this format I have

if comming from other file format dynamic playlist (ogg and mpc where tested) the player just freeze without any reaction on wps, having deteced correct format and file lengh (one time screen corruption was observed, coming from ogg)

arf: the second data abort is of course starting with Data abort at 63E74578
meanwhile I just get a third one:

Data abort at 63E712C0
FSR 0x1
(domain 0, fault 1)
address 0xFFFFFFFB
backtrace start
pc: 0x63E712C0
sp: 0x00005280
backtrace end

should I find_address them? And if so I not really sure about the context argument (I mainly always give 1 as in the example given - is it the way to do?)

The dummy array in that patch will not fit on the stack.

Good point. The updated patch should take care of that,

Still the same problem from mp3 playlist that must be related  FS#12429  then
If the music is stopped before the patch work.

hum wait I tested 2 complete files they started to play ok and at some random point in the file they get skipped into the next one...

Just a minor change after checking the code against ffmpeg's code.

no change, sorry... But I can confirm that the data abort also occurs with "normal" flac

> But I can confirm that the data abort also occurs with "normal" flac

You mean your device has this issue with "normal" (=stereo) flac and the patched decoder? Or does this also happen with svn?

WOW good point, I kind a forget this! But actually, the data abort seems systematic with any kind of flac coming from mp3 and also occurs in svn... So I've made a new report for this  FS#12442 

So, the patch fixes the 5.1 playback for you, but you still have another general issue.

no I can't say that because the file get only partialy played and then skipped (anyway with the number of issue with flac file on fuze+ it will be difficult to say. The file should be tested on another device I think) Problem, the files are huge: between 200MB and 300MB each!

This patch fixes the unwanted skipping for me. Main issue was a too small MAX_FRAMESIZE.

Nice! I confirm this is working here too! But I get ugly compiler warning:
/home/jean-louis/Bureau/rockbox-devtree/rockbox/apps/codecs/flac.c: In function ‘flac_init’:
/home/jean-louis/Bureau/rockbox-devtree/rockbox/apps/codecs/flac.c:97: warning: assignment from incompatible pointer type
/home/jean-louis/Bureau/rockbox-devtree/rockbox/apps/codecs/flac.c:98: warning: assignment from incompatible pointer type
/home/jean-louis/Bureau/rockbox-devtree/rockbox/apps/codecs/flac.c:102: warning: assignment from incompatible pointer type
CC apps/codecs/libpcm/adpcm_seek.c
CC apps/codecs/libpcm/dialogic_oki_adpcm.c
/home/jean-louis/Bureau/rockbox-devtree/rockbox/apps/codecs/libffmpegFLAC/decoder.c: In function ‘decode_frame’:
/home/jean-louis/Bureau/rockbox-devtree/rockbox/apps/codecs/libffmpegFLAC/decoder.c:478: warning: passing argument 3 of ‘decode_subframe’ from incompatible pointer type
/home/jean-louis/Bureau/rockbox-devtree/rockbox/apps/codecs/libffmpegFLAC/decoder.c:297: note: expected ‘long int *’ but argument is of type ‘int *’
CC apps/codecs/libpcm/ms_adpcm.c

This patch fixes the warnings.

Tested. Works without problem here, normal flac works too. No more warnings. Good job!

A few people have reported that stereo flac files sounds a bit odd with this revision:

<maal> Hi all, i think this commit : http://svn.rockbox.org/viewvc.cgi?view=rev&revision=31207 has broken stereo flac playback.
<maal> I tested on my sansa fuze v2 : r31206 - playback is ok, with r31207 - channels "are mixed" (hard to describe)

I cannot see anything wrong with the changes. w/o any reference file which shows such issue I cannot really proceed on this...

Edit: I already tested two stereo flac files and they have bit-identical output for r31206 (before the latest change) and r31237 (current svn).

see in IRC log the comments of Misanthropos starting at 14:48 on 14th december

Attached file is played wrong with r31207