skin_buffer_to_offset() call can never return a "negative" pointer
(since it just returns the pointer as-is) so don't bother to check.
Change-Id: Id86d53abd7ab1fb071ca54421ebe3b5ff2981c02
add get_metadata_afmt function so we don't have to extra functions
remove unneeded bounds check on audio_format in rbcodec_format_is_atomic()
add bounds check on audio_format in get_metadata_afmt()
Change-Id: I76bd869100b000579c6546f0670ba4ba2c541f22
tagcache.c add_tagcache() and potentially
skin_tokens.c wps_playlist_percent_prepare()
make calls to probe_file_format() prior to calling get_metadata_ex
resulting in some small amout of duplicated work
especially in the case of add_tagcache this can add
up to a lot of duplicated work
breaks out audio_fmt so these can supply the afmt other callers just
supply probe_file_format(trackname) in the function call
Change-Id: I8084213b8ee7e04d76dce0986beb83d443ac804b
%pP reports playlist progress by position index, which treats every
track as equally long. For playlists with tracks of unequal length --
audiobooks with chapters anywhere from two minutes to an hour are the
motivating case -- position is a poor proxy for listening progress.
%pX reports the played percentage of the whole playlist by time: the
summed length of all preceding tracks plus the elapsed time in the
current one, relative to the playlist's total duration. It can be
used as a value, in a conditional, with %if(), or as a bar tag like
%pb.
If a playlist contains more than 500 tracks or the scan is taking too
long and the user aborts the tag will fallback to the behavior of %pP
except the progress through the current track will be included in the
returned percentage
--------------------------------------
Computing this needs every track's length, and reading metadata for
every track is too slow and disk-heavy for a tag that refreshes on the
WPS. Instead each track's length is estimated from its file size: the
skin engine scans the playlist in the background, a batch of files each
skin refresh, opening each file only to read its size (directory
metadata, no header parse). Size is turned into time by calibrating one
file of each type -- the first file of each extension is parsed once
with get_metadata to learn its bytes-per-second, and every later file
of that type reuses it. A single-format playlist, the usual audiobook
case, parses exactly one file and stat's the rest.
The result is an estimate -- bitrate varies within a type, especially
for VBR -- but it is cheap and accurate enough for a progress
indicator, and the playing track always contributes its exact elapsed
time. Per-track lengths are stored as two bytes of minutes each in a
movable buffer sized to the track count and allocated only while the
tag is in use; the cache is keyed on the track count and a crc of the
first, middle and last filenames, so a playlist swap or reshuffle is
caught. If the buffer cannot be allocated (a very large playlist on a
low-memory target) the tag falls back to position-based progress.
The buffer is allocated when playback starts (and when the now-playing
screen is opened with playback already active) rather than lazily on the
first WPS refresh, so the one-time allocation happens at a playback
boundary instead of during steady-state playback; it falls back to
allocating on first use if that point is missed.
Until the scan finishes the tag does not blank: it returns an instant
equal-weight estimate -- (completed tracks + fraction through the
current one) / track count -- which sharpens into the size-based value
as the scan fills in. So a theme can just use %pX and it is correct
from the first frame, and %?pX is true whenever a playlist is loaded.
Tested on a Sansa Clip Zip and in the simulator. On a 216-track,
~745 MB single-format audiobook playlist the length scan dropped from
~4150 ms (get_metadata on every track) to ~174 ms (one parse plus 215
file-size stats), roughly 24x lighter.
Change-Id: I6e572e78a10444bd513ddc77e30da04aa5153ef2
currently logf() in codec are printed unconditionally when
ROCKBOX_HAS_LOGF, which is confusing.
Gate them behind LOGF_ENABLE to align with the main binary.
Change-Id: I4eb44604000acded55d0af8869145c4f3d77efcb
clang defines both of __LITTLE_ENDIAN__ and __mips__, causing
confusion in the byte order detection.
Change-Id: If95255974e9e3e5d0554410bbab65bc2af1bb1c7
Load stts (time to sample) table on demand if it doesn't fit in RAM.
Fixes FS#13889 (in most cases I've seen files with single element in this table and problematic one has 111200 elements)
Change-Id: I719f92a4512a45472739587e81861b9bc545f349
GCC16 is stricter about reporting these, and while we can rely on
the compiler to optimize away dead stores, we're better off eliminating
them from the source code.
Change-Id: I14570a986811a77ca656c60d792593ff8c458571
Make sure the output of strchr(const*) is assinged to a const*
This way the filename argument can stay const
Change-Id: Ie46be936491eb62ba2a7e729b8cd7881e205bba7
* Funky macro-based definitions for memchr and strstr
which require an #undef before we use our own in codecs & plugins
* Return value of of strstr is const
Still have several more warnings and link failure with some plugins
but this is a good start.
Change-Id: Ife1f2d3e6f0e0629e3125a9058abc39c6102f452
-fstack-protector only needs a small amount of runtime
support to work on native builds. It increases code size
by ~1.5% on ARM/MIPS; -fstack-protector-strong adds 3-4%.
This is disabled by default and must be enabled by passing
'--with-stack-protector' to configure.
Change-Id: If952e711d3673c9b469895f08c7bff70b3d95df6
- Move all devkitpro includes before the Rockbox ones so that the macros which are both conflicting and unused can be undef'd
- Remove unused result variables
- Exclude an unused function from being compiled for this target
- Fix hex number formatting
- Fix the return value of dummy functions
- Fix macro redefinition in the plugins keypad config
- Remove duplicate button mapping
- Turn off -Wchar-subscripts as it's already handled in Rockbox's ctype.h
Change-Id: I3f5a3d492c585f233277a380feaea5fe877a044f
Check for USE_IRAM to determine if IRAM should be used.
SoCs that don't define USE_IRAM no longer need to define
IRAMSIZE to 0 either.
When IRAM is not used, any symbols bound for IRAM will
be discarded instead of linking them in DRAM. In theory
these symbols shouldn't exist, since nothing should be
placed into IRAM sections to begin with for !USE_IRAM.
If an IRAM section attribute leaks into the plugin/codec
anyway, it should now cause a link time error.
Change-Id: I55c1854cfe8beb5cb09b865336906f9945084b33
Mostly motivated by PP needing CACHEALIGN_SIZE in linker
scripts, which can't include system.h, so move these to
cpu.h instead. Also gets rid of the default 32 byte line
size that was used if the target didn't define alignment
itself. RK24xx, DM320, and JZ4740 were missing this but
have been confirmed (from datasheets) to use 32-byte cache
lines.
Add checks to make sure the macros are appropriately
(un)defined based on the HAVE_CPU_CACHE_ALIGN define,
and make sure their values are consistent when they
are defined.
Disable HAVE_CPU_CACHE_ALIGN for hosted targets since it
arguably doesn't matter if there's a cache, if we aren't
responsible for cache maintenance.
A few files in rbcodec use CACHEALIGN_SIZE, but these
can be converted to MEM_ALIGN_SIZE, which is identical
to CACHEALIGN_SIZE if the latter is defined. On other
targets, it aligns to at least sizeof(intptr_t).
Change-Id: If8cf8f6ec327dc3732f4cd5022a858546b9e63d6
Due to the unicode data tables, this is a pretty large library,
adding ~340K to the binary size (ie a 50% increase on some targets)
Note that nothing in-tree actually _uses_ utf8proc yet. The plan:
1) In the metadata parser, fully normalize+compose all strings.
2) When looking up font glyphs, if we do not find an exact
match for the codepoint, try to decompose and render the result.
3) Normalize all filenames as we read them, ie before we store them
in lists or compare filenames/pathnames.
4) Use utf8proc for casefolding-aware sorting (on native devices)
Change-Id: I2252cee3e7891d12ff37867231aa2c20353f857b
Looks like I forgot to test the hosted builds and for some
reason thought that make would expand objcopy recursively...
Change-Id: I61264eadcb1235660566f6a9f19f8718ebe14583
This reverts commit 91ec6f1e1e.
Reason for revert: Massive sea of red, looks like hosted + sim builds.
Change-Id: I98a3954d68ad2cc521e13c3683bf4a6f45f88b36
From what I can see the Creative Zen Vision ports, which
were the only ones to set USE_ELF prior to the Echo R1 port,
do not work except for a bootloader and never even got to
the point of booting Rockbox. This explains why they build
codecs and plugins as ELF binaries, yet there is no code to
load ELF format codecs or plugins.
Anyhow, add a new setting, PLUGIN_USE_ELF, which controls
whether plugins & codecs are left as ELF or converted to
flat binaries. This makes it possible for the Echo R1 to
use the flat binary .rock format, and makes it possible to
have ELF plugins/codecs on targets with non-ELF main binaries.
Seeing as nothing needs ELF plugins/codecs right now, the
new default is to generate them as flat binaries unless
the target requests otherwise.
Change-Id: I9ffae669978de5cc7ad214cd50d97ad6e8938394
b64_codes is unsigned on some systems unless explicitly
declared as signed.
"b64_codes[index] < 0 comparison is always false due
to limited range of data type [-Werror=type-limits]"
Introduced in 849e8ab
Change-Id: I6a86e898c2ed8995f7346060f9b9b58ea6ab1e95
This new tag returns the position in the playlist as a percent. The main usecase for this is to use it as a bar tag, allowing themes to visually present playlist progress.
Change-Id: I0eb001e7458d97b8a0db39f3980d9c283bc8806b
Some of the inline assembly generates "impossible constraint"
errors in this function, but only when DEBUG is enabled.
Change-Id: I3b1135a8a55436bd3068ef560ebcef64a5184a05
Move HAVE_CODEC_BUFFERING to config.h, and disable all
related code on targets that don't support the feature,
ie. hosted targets that can't implement lc_open_from_mem().
Change-Id: I0d2a43900cd05b1a80c3cee519f8ad7b26e39fe7
Most notably for CD rips that use a track number of 0 for
the leadin.
Therefore change our "invalid track number" canary to -1 instead
of 0. Additionally don't try to parse an empty string.
In the process, get rid of redudant 'discnum = 0' as well.
NOTE: While not strictly necessary, we recommend rebuilding the
database to ensure files without track numbers are
updated with the new canary.
Change-Id: I543f98ca49cec7b5eeffa7c14c1eca57171f345a
These were lifted from the lua plugin.
sdl, doom, puzzles updated to use the exported version
todo: lua, maybe?
also: convert uses of atoi [back] to strtol
Change-Id: I5a1ebbe8d8c99349e594ab9bbbce474e7645b4e9
* Detection of 64-bit Arm v8-a
* Proper detection of integer division support
* always on v7-m, v8-a, v9-a, v8-m.main
* sometimes on v7-a, v7-r, v8-r
* never on v8-m.base v6-m, v6 and older "classic"
* tl;dr: Rely on toolchain preprocessor definition
For the most part these additional variations won't acutally work
for native target builds, but sane -A detection is needed for
"local" builds now. -R detection is left out as it's not likely
to matter.
Change-Id: I8f6a52edc4d14490fc00e2f487406eca701eef02
Simply knowing that a touchscreen is present isn't that useful for
themes. Having %Tp evaluate as true when in pointing mode and false
in 3x3 mode is better. For example, themes can change their layout
or hide touch UI elements when in 3x3 mode, or show a status icon.
Although a similar effect can be achieved with the %St tag it's
simpler to use %Tp for this purpose -- it can report the current
mode, not just the user preference.
Change-Id: Ie343c105970dca11864fa44c6a091ed8e9e35b3d
Does not seem to affect UI usability, but allowable DSP loads will vary
based on device and playback sample rate.
To-Do (someday):
- Add dedicated DSP channel
- How to apply DSP settings to above new channel? (UI)
- How to lock out timestretch from being enabled?
Change-Id: Ia24d1055340354e2c32e6008e7e2b03a8e88867d
This commit adds changes to the original rockbox sources.
Note: the port files, functions, folders, etc., will be referred
to as 'ctru' to avoid using the Nintendo name elsewhere.
Change-Id: I0e2d3d4d2a75bd45ea67dc3452eb8d5487cf1f5a
asm volatile (
"mov %[t0], %[out], asr #11 \n"
"mul %[out], %[t0], %[envx] \n"
: [out]"+r"(output), [t0]"=&r"(t0)
: [envx]"r"((int) voice->envx));
This is resulting in "Rd and Rm should be different in mul" error,
because the compiler is putting [out] and [t0] into the same
register.
After some poking there doesn't appear to be a sane way to change
the constraints, so just disable it for now.
Change-Id: I7827713c8aadb27f0bf4a6f4a3e1d910c6193686
We used 16-bit variables to store the 'character code' everywhere but
this won't let us represent anything beyond U+FFFF.
This patch changes those variables to a custom type that can be 32 or 16
bits depending on the build, and adjusts numerous internal APIs and
datastructures to match. This includes:
* utf8decode() and friends
* font manipulation, caching, rendering, and generation
* on-screen keyboard
* FAT filesystem (parsing and generating utf16 LFNs)
* WIN32 simulator platform code
Note that this patch doesn't _enable_ >16bit unicode support; a followup
patch will turn that on for appropriate targets.
Appears to work on:
* hosted linux, native, linux simulator in both 16/32-bit modes.
Needs testing on:
* windows and macos simulator (16bit+32bit)
Change-Id: Iba111b27d2433019b6bff937cf1ebd2c4353a0e8
High-frequency files increasingly use a block size of over 4608B, which
means we need larger buffers to decode them. However, larger buffers no
longer fit in IRAM on less-capable devices, hurting performance for
"normal" file playback.
On our slowest devices (M68K and PP-based devices), this is not worth
the tradeoff as they will likely not have enough CPU oomph to decode and
downmix these files in realtime.
S5L87xx-based devices have the raw performance to do this, so we decided
to err on the side of wider file compatibility at the cost of some
performance.
All other devices are unaffected.
Change-Id: I7344cf4c8c6b7b5c14f1ea67381160665d6ece5b
