Crossfade broken?

[jhMikeS]

I know exactly what's happening now. Yes, it's due to short tracks not being handled gracefully. PCMBUF sees an auto skip (end of playlist is always auto skip), and the file is short enough that the crossfade is still active at the time, so it bails out (apps/pcmbuf.c line 703). It's not specifically end-of-playlist; having three files in the directory after the two provided will cause a bail on the second and transition to the third.

So, I got this one and have a couple more bugs in the heap that need to be handled. I've been derelict lately.

[chrisjj]

Yes, it's due to short tracks not being handled gracefully ... the file is short enough that the crossfade is still active at the time

Note that the fail occurs even when the 8s crossfade is (or should not be) still active at the time of the end of the 10s file, e.g. https://www.dropbox.com/s/ror2v8gwxbeqjwi/RB%20Crossfade%20fail%20on%20immediate%20skip.mpg?dl=0 .

But yes I do see the fail does not occur with 20s files: https://www.dropbox.com/s/hbwwuizqrqg28ym/RM%20Crossfade%20fail%20absent%20on%2020s%20files.mpg?dl=0

BTW, here's another case for verifying the fix. Instead of a Next, Files Select: https://www.dropbox.com/s/q1vxhibvb3b4f7w/RB%20Crossfade%20fail%20on%20Files%20Select%20second%20track.mpg?dl=0

[jhMikeS]

Let's just say I know for a fact it's running that line in pcmbuf.c which will discard any PCM on the buffer. Selecting from the file browser is just a manual skip to playback.

[chrisjj]

Fix seen here https://git.rockbox.org/?p=rockbox.git;a=commitdiff;h=6c837394ca6d7a988bfbdc9e97630e69f0bc2025 .

Thanks. Looking forward to trying it!

[jhMikeS]

NP. I was going to put something here about it but the forums weren't responding so I figured I'd try again later.

[saratoga]

By the way, do you know why people have reported slower database building on hard disk players since the file system rework? As I recall the new system was faster in most tests, so it's surprising that the database did not benefit.

[jhMikeS]

Which players? I do have hard disk players and didn't see anything horrible in the times. Perhaps the TC ramcache stuff is behind it since it got disabled for the moment (it would have just made the changes even more massive and was no longer compatible with the revised version). I got sidetracked by events and didn't finish what I intended to.

[chrisjj]

By the way, do you know why people have reported slower database building on hard disk players since the file system rework? As I recall the new system was faster in most tests, so it's surprising that the database did not benefit.

I don't know the RB db code but my experience of other audio metadata DB builders tells me there's opening of many large files and reading of relatively few bytes from each - a usage pattern unique to DB building that could be slowed from an update that would accelerate performance overall, and not be covered by tests that covered other filing system usages.

[chrisjj]

Fix seen here https://git.rockbox.org/?p=rockbox.git;a=commitdiff;h=6c837394ca6d7a988bfbdc9e97630e69f0bc2025 .

Thanks. Looking forward to trying it!

The track loss fix is verified here. Thanks!

But crossfade shape is bust. Fade-out delay missing and duration diminished:



Again that's a 10s track.

On a 20s track with skip near start, the shape is correct:



But near end, exhibits the same fail:



This fail strikes every track I've tried regardless on length, when the fade is e.g. 8s from the end.

FWIW, Auto Track Change (on both lengths) is correct .