docs/KNOWN_ISSUES - rockbox - Gitiles

 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...
	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...