ipod6g was configured with SECTOR_SIZE of 4096, but this ATA driver
unconditionally translated these to 512B operations on the actual
storage device.
Rockbox's storage layer already has robust support for "logical sectors
larger than physical storage sectors" through use of
MAX_LOG_SECTOR_SIZE. So switch to that mechanism, allowing the ipod6g
ATA driver to be simplified.
If we want to support drives with physical sector sizes > 512B, then
we need to port the MAX_PHYS_SECTOR_SIZE logic from the primary ATA driver.
Additional changes:
* Simplify MWDMA/UDMA selection logic
* Report CE-ATA mode in debug menu
* Use LBA48 commands only if drive is over 128GiB.
* Drop default sleep/poweroff time from 20s to 7s (matching main ATA driver)
Finally, the bulk of the changes are the first phase of a badly needed
style cleanup that made reading this driver a lot harder than it should
be. I intend to split this into a separate patch.
Change-Id: I2feca9fd319c8d6cfb3c2610208970428d2fa947
And fix up all the problems I've found so far.
...This will undoubtedly introduce a pile of new warnings.
Change-Id: I868de507a0e9790f289676c198e2977c26755f22
Since commit e0df995 storage_disk_is_active may be 0
even if there is no disk that needs to be spun up or
device to power on, so it doesn't really make sense
to check for it, anymore, in order to decide whether
to display the loading indicator.
For remaining devices with spinning disks, the noise
or vibration of the disk spinning up may serve as a
sufficient signal when loading a plugin, that the
device isn't frozen. Plus, for the tagtree, search
progress is displayed after 0.5s anyway.
Change-Id: I5791725e2388d7113818a358204968d8a4e6f843
Added jpeg decoder jpegp.c using RAINBOW lib. Currently enabled only for pictures not supported by old decoder (as old decoder more optimized for low mem targets)
Someone TODO:
* Old decoder has optimized downscale logic which new decoder doesn't have (it gives big difference in required memory and time for decoding). This logic should be ported/adapted if possible.
* Add smooth downscaling.
* Grayscale support
Change-Id: Ie96bc62848b51cc6a3942f8e069ec6ab02dc1c56
Added unmodified files from RAINBOW library by Attila Tarpai
Full sources:
https://github.com/Halicery/vc_rainbow
Change-Id: I356486b6a332aa3f610ddcae57f8a2044653b051
Code has no effect since commit a0e95c8.
Functionality is now handled by the playlist_insert_context_add function
Change-Id: Ie91f605bd7a7d03556fa70d195a06bc55866741d
If you have say 1000 playlist entries and select the 1001 song in the directory
dirplay loads tracks 1-1000 shuffles them and track 1001 is never heard from again
Instead start at the file and loop through the directory mod dir len
Change-Id: Ieded5decdc1f7c44b1be8491dbd4f359ae21f79a
Hint: this is a good way to not wait on dirplay to load a ton of tracks
On usb plug system_flush() gets called before the other
threads get a chance to ACK the insert
system_flush() calls playlist_shutdown() (amongst other things)
playlist_shutdown closes the control file
the audio thread acks USB insert
audio_stop_playback is called which now can't look up the
filename from the now closed handle for control the control file
I left the guard for checking for USB insert but it appears to be
fine without it
Change-Id: I935dbf7aed38d4a57413c0063ad953f427e9b3bb
I forgot we had duplicated code between playlist.c and tagtree.c this saves
a bit of space and should speed up adding tracks a bit
further I noticed a buf here where there was the potential to return without closing
the opened track search
Change-Id: I15ed8447fc4fe13de5bfeb9fbb59b151e2fbf36a
with our large voice file being loaded in its entirety to the buffer
there isn't enough room to allocate the required pcm buffer
well prior to this patch we looked for 1k free to allow the talk buffer
to be given away
well the pcm buffer expects something like 5-600 kb on the clipzip
and there is 1k allocatable but not 300 more
so instead get the required pcm buffer size and check against that
Change-Id: I40a056e4170c37bc3429f0cb37af221ae7f812e5
<..> gets interpreted as a drive/volume ID, which has special voicing rules.
(this is especially visible in the DB browser)
Change-Id: I7c2598004a4e58451267d77f786eb52f7c09bd3f
it was hard to hit this branch, I had to comment out:
ln 555 else if (offset == 1)
ln 556 pid3 = state->nid3;
as far as I can tell the reason for the separate filename buffer
was due to the failure mode of audio_peek_track() wiping
the id3->path, stands to reason for me that we can just fill it
again
-Already found a gotcha playlist_peek() mutates the buffer
makes me like this solution less, might rework tagcache_fill_tags()
instead
--Fixed
Change-Id: I4a2ee71a8e2d0739c9e141948b71c2ed36296e3b
- Korean (Hoseok Seo)
- Polish (Adam Rak)
- Simplified Chinese ( 王吉)
- US English (Solomon Peachy)
Change-Id: Id5fa80d1d6711cdcb93d158ff014552732168e18
If you have a lot of tracks loaded in a database view and play a
track it builds a playlist and puts you into the wps
if you stop playback and exit the WPS you are immediately
loading entries that were just loaded
if you return to the database again reload data thats probably
still there
this patch gets a crc of the data and if it matches reuses it in
the tagtree rather than reloading it
Change-Id: Ice3aba7569f19afdd1627ba18c2dc781f98cbf93
Offer new options to show elegantly your entries in any playlist/dynamic playlist viewer. This is especially important if you dual boot an iPod with Stock OS and want to sync with iTunes; with this very popular setup, file names are obfuscated which results in any Rockbox playlist viewer difficult to enjoy, and it was a long standing issue reported by several Rockbox users over the years. The only way to show the title was to open a contextual menu on each song to get infos about the selected song, which is a very long and anti-ergonomic process to understand what is on your current playlist/randomized playlist. The idea of this patch is to provide new alternatives that the user can select. I personally selected the Title & Album view which provides excellent readability.
This patch was built with performance in mind using lazy loading to load one by one the tags then cache a string and use the little cache as much as possible to make scrolling in the same area as smooth as possible. Performance remains very acceptable even on an iPod 4G with its original hard drive. Using a real compact flash with my iPod Mini 2G reduces the latency even more.
Those new options are disabled by default because they impact noticeably the scrolling performance and are less relevant if your files are decently properly named.
Unfortunately, the search feature in a playlist will need to continue to use the raw filename because reading the tags for a whole playlist is a performance disaster. This works decently while viewing just because I made a code that load those one by one as much as possible.
I focused also on testing that the opening of the playlist viewer UI remained fast, and loading one by one with lazy loading allows to get very little overhead in this regard.
Change-Id: I00d9c802e29f8372447813b035bbae207a016467
this is a bit cleaner without so much ram (or code) used
Credit to goes to Paul Sauro (OlsroFR) as this was his idea
if available space exists in the pluginbuf it uses fisher yates
shuffle to get good probability
and falls back to random permutation if not
Change-Id: I413078a48314ce4c6f3722c78e0858a407b7b46e
This improvement brings a huge performance improvement to start a random mix of your library. Previously, the only way to do this was to increase the size of a playlist with absurd sizes number. Now it will respect the limitation but will insert random songs from the current view.
Database: Add true random songs in playlist if it is gonna exceed its maximum capacity
More context is available here : https://www.reddit.com/r/rockbox/comments/1ez0mq4/i_developped_true_full_library_shuffle_for/
Also :
- Improved layout in the DB browser
- New default max playlists capacity is now 2000 on old PortalPlayer targets to give a better user experience and not having to wait dozens of seconds while creating a playlist
- "Show insert shuffled" option is now true by default
- Add a new shortcut to play all songs shuffled in the DB browser
- Now the feature is fully optional and enabled only on targets that have more than 2MB of RAM
- Add entries about this feature in the manual to explain it to the users
Change-Id: I1aebaf7ebcff2bf907080f1861027d530619097c
Change-Id: I3354923b148eeef1975171990e814a1a505d1df0
