summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
authorSolomon Peachy <pizza@shaftnet.org>2020-07-07 01:27:40 -0400
committerSolomon Peachy <pizza@shaftnet.org>2020-07-07 05:31:25 +0000
commit52325a7c016f19a711e25f2f381b34d95c95f46a (patch)
tree3d5f432e708c67e785c21b127fa27e7f8bb4975b /docs
parent5094aaa4d49573c0491399e987c2c866c00796a5 (diff)
downloadrockbox-52325a7c016f19a711e25f2f381b34d95c95f46a.tar.gz
rockbox-52325a7c016f19a711e25f2f381b34d95c95f46a.tar.bz2
rockbox-52325a7c016f19a711e25f2f381b34d95c95f46a.zip
docs: Get rid of the long-obsolete KNOWN_ISSUES file
Change-Id: I6ed1a96f690f6ff227e9abb1e9815e9e36914f32
Diffstat (limited to 'docs')
-rw-r--r--docs/KNOWN_ISSUES42
1 files changed, 0 insertions, 42 deletions
diff --git a/docs/KNOWN_ISSUES b/docs/KNOWN_ISSUES
deleted file mode 100644
index 4ae88cb9fd..0000000000
--- a/docs/KNOWN_ISSUES
+++ /dev/null
@@ -1,42 +0,0 @@
-This is a list of known "issues" in the current Rockbox.
-
-These are flaws/bugs we know of that are not likely to be fixed within a
-reasonable time so we list them here and close the bug tracker entries for
-them.
-
-FS#894 - When the complete playlist fits in the mpeg buffer, and the playlist
- is played multiple times, the tracks are reloaded from disk multiple times
- instead of loaded only once.
-
-FS#2147 - It's a bug in the MAS. It starts bitshifting data on occasion. High
- load on the MAS makes this behaviour more likely (high recording level, high
- quality setting, high sample rate). It's impossible to avoid, but there are
- plans to implement a recording 'framewalker' that checks recorded data and
- restarts recording when the MAS starts delivering bitshifted data.
-
-FS#4937 - A constant rhythmic ticking noise occurs in the right
- channel. Believed to be related to our slow I2C implementation, and occurs
- when the battery status and/or realtime clock are updated (the battery is
- read at up-to 2.5hz and the clock at up-to 1hz). Nothing is going to change
- with it until someone spends a lot of time analyzing the portalplayer's I2C
- control registers, or finds a datasheet for the damned thing.
-
-FS#5796 - Early encoders such as this one employed a floor of type '0', as
- opposed to the more efficient/cheaper floor type '1' which has been used in
- all encoders from libvorbis 1.0 onwards, I believe.
-
- The problem appears to be that most DAP decoders can only handle a floor of
- type '1'.
-
- While floor '0' type files like mine are, it turns out, pretty rare, they
- still conform to the standards, as can be seen in the documention linked
- below:
-
- http://www.xiph.org/vorbis/doc/Vorbis_I_spec.pdf
-
- which specifically states that "Floor 0 is not to be considered
- deprecated..."
-
- Files like these require quite a bit of memory to decode, more than what
- Rockbox has set aside for the purpose. Adding a real malloc for the codecs
- might help...