Most of the 'perfect' or 'good' translations are covered.
Also, don't override user-specified voice
Change-Id: I837bd67e9df2b8bcc7e020f12a2f411c9175565b
Uses the 'gtts-cli' command line client. Supports a wide variety of
languages, including all "Complete" and "Good" Rockbox translations.
Additional changes:
* voice synth script can accept pre-encoded mp3 files
* Move language->synth options mapping into the voice script
* Additional cleanups
Change-Id: I9523e2bca87cbcee2d8c4111f9892e8e458c7419
The last successful build was 87c6df9-131213, shortly after the 3.13
relase, but even before that, it had been problematic due to severe
firmware image size limitations (200KB) of the hardware bootrom.
(Current git code genrates an image about 220KB)
Change-Id: Ibaf7bd61cbc0f0656c5e119bbb9934437aa9c47c
In addition to version and target also check id1_max & id2_max
for proper length before allowing voice file to be loaded
Change-Id: I36016059d07781b0bb43dd9873bbb6e565298d76
DX50/DX90 has a Cortex-A9 with NEON, use those specific flags
for speed.
Generic Android targets is for v4.4 (API 19) which doesn't support
pre-v7 ARM CPUs, so target generic armv7-a with hardfp support.
(This patch includes a rearrangement of the android toolchain helpers to
allow target-specific GCCOPTS. Huzzah)
Change-Id: I696051ef3fae25e1569c7b904decb7a3a0c6b674
The oldest verison of the NDK one can still download today is version
10e from mid-2015, which comes with GCC 4.9, and no longer supports
32-bit hosts.
With this, one can actually compile the iBasso DX50/DX90 targets again,
as well as the generic android target, as long as one has the correct
SDK platforms (v16 for ibasso, v19 for generic) and SDK tools installed.
Change-Id: I62f2e742d5cfc13133244aeff75a928a7294ac91
Provided by Roman Stolyarov
Integration, Refactoring, and Upstreaming by Solomon Peachy
X3II confirmed working by forum tester, X20 is nearly identical.
This includes bootloader, main firmware, and the flash image patcher.
Eventual Todo:
* Further refactor AGPTek Rocker & xduoo hiby bootloaders
* Further refactor AGPTek Rocker & xduoo hosted platform code
Change-Id: I34a674051d368efcc75d1d18c725971fe46c3eee
This frees us from having to keep the web site in sync.
Note that only currently-referenced patches were kept.
Change-Id: I50da1b75baeac214cf142c8b76a05a8c56b4c1d4
(From Stefan Ott)
I wrote a little patch for ipod_fw.c that allows me to create bootable
images for the iPod video without using any external software.
The patch adds two new options:
- The -s option can now be used to specify the sector size in blocks (typically 512 or 2048) when generating an image.
- The -n option can be used to create an image without a boot loader
Change-Id: I35ebcd19ba1491bba76dfc8011e5a856108bb9ad
This adds tools/list_targets.pl and tools/build-info.pl. list_targets does
exactly what it sounds like - it lists targets by target status. build-info
automates the generation of build-info.release for new releases.
Change-Id: I4c859fdeb54c8cc645832a7c4192f9d18590031e
This simplifies the tedious task of building all the Rockbox
toolchains manually by providing a build code for a Docker container
image. It's useful for quickly spinning up a build client with just a
couple commands and no waiting to compile (though downloading takes a
little while).
I've built an image as built1n/rbclient on Docker Hub.
All toolchains (even the weird ones) are included, except android16.
Change-Id: I6b863628ffb397604f59ec6def2f8bb8c8c7185f
paths.
If ROOTDIR=/rockbox and BUILDDIR=/rockbox/build-something, it is now possible to
successfully build both target binaries and simulators.
Change-Id: If12d1d5933c5a15feebf627a4f1636dc1e3a67fa
Vagrant is an application that automates creation and provisioning of a virtual
machine for development. The config here creates an Ubuntu 16.04 LTS machine,
updates it, downloads and installs the toolchains for sh, m68k and arm,
mingw-w64, SDL (for Windows simulators) and other packages needed for building
Rockbox.
It works fine for building a Windows simulator and compiling iPod classic
binaries. It should be possible to make the other build types, too.
MIPS toolchain fails to build, ARM-APP is not tested because the files download
very slow on my connection. Please test if it works for you, and let me know.
Quick start: download and install Vagrant and VirtualBox for your operating
system, make sure VT-x / AMD-V is enabled in your BIOS/EFI setup, open a
shell in rockbox/tools and input the command "vagrant up"
Change-Id: Ief5476ab066663a4db7e85404b25d2d781d90532
As rbcompat.h is -include'd on the command line, the mkdep script doesn't
pick it up. Explicitly add the dependency to lang_enum.h to the makefile.
Also add lang_enum.h to the 'make clean' target!
Change-Id: I33c8ed0cd5c1d44dce02ac9285469c0e4feac00e
Original patch by Mario Lang
Heavily updated by Igor Poretsky
Further updated by myself
This patch breaks binary API compatibility by placing the new
functions where they make the most logical sense. IMO this is
the better approach to take given the scope of the changes needed
for talk support.
Since binary API is changing, the patch also moves some other
functions around to more logical locations.
As well as voice support in plugins, this patch voice-enables several
simple plugins. There will be follow-up patches for many plugins that
build on this one.
Change-Id: I18070c06e77e8a3c016c2eb6b6c5dbe6633b9b54
For unknown reasons, -thumb builds need -lfirmware after -lrbcodec (but
still before -lunwarminder)i. Other builds are still happy if we do that.
Including it via CORE_LIBS instead of explicitly achieves that.
Change-Id: Id69e4a0c042f90f71cfd9a72202ce4d8ef6a4181
I use this to test duke3d in the sim, because it does some nasty pointer
arithmetic with 32-bit ints.
Should be useful for other things as well.
Change-Id: I807c81b32c61538de9edc3fca77fde193dc4e617
* bmp2rb generated a .h file that rockbox .c files used.
* .h files in .c files were used to generate dependency graphs for make
* When Make saw the .h file for the bitmap, it didn't know how what
to do with them
* Only arose in parallel builds
Fixed this by adding explicit dependencies for the .h files as part of
the existing 'bmpdepfile' function.
Solves the Xduoo X3 bootloader build failure that I could trigger 100%
of the time by using 'make -j8'
Change-Id: I6b3e78dde26c820a3b6c7c286e7d6c981b8e01fc
I realized there was a better way to do this..
Instead of specifying a path just have gcc run the preprocessor (-E) on
an input file consisting of only '#include <byteswap.h>' if it succeeds
then we can use it if not then don't define OS_USE_BYTESWAP_H
Change-Id: I0de8e469445221bc1b5ad8cc032de5b89a85ab66
