It sort of implemented an MRU cache but just kept track of the most recent access and checked the one after it, otherwise searching from the beginning. Implement a true MRU list of all open handles. Handles of the current track will tend to stay up front for faster access. Switch to common linked list functions Use double-linked lists to have insert, remove and move_handle operations in O(1)-- no more searching to find the previous handle, which is very often required. Smaller code too. :) Change-Id: I9ae8f3f96d225a5d54b94133f499268007274784
I'm not sure all the situations it affects, to be honest. The fix aimed to address the strange symptom here: http://forums.rockbox.org/index.php/topic,50793.0.html It turns out that ringbuf_add_cross was used when handles were butted up against one another with the first parameter equal to the last, which it interprets as being an empty case when it should be interpreted as full in the context it was used. To fix this, introduce full/empty variants of ringbuf_add_cross and ringbuf_sub and use them at the appropriate time. The other way to address the problem is ensure there's always at least a space byte between the end of one handle and the start of another but this make the code a bit trickier to reason about than using additional function variants. bufopen() may yield after creating a handle and so do some more locking so that the buffering thread doesn't mess things up by moving anything or not seeing the yet-to-be linked-in allocation. Add alignof() macro to use proper method to get alignment of struct memory_handle. That should be useful in general anyway. It's merely defined as __alignof__ but looks nicer. Change-Id: If21739eaa33a4f6c084a28ee5b3c8fceecfd87ce
Change-Id: I10aac94906607a74f05a687cb3d0029cb6faea6e
HAVE_IO_PRIORITY was defined for native targets with dircache. It is already effectively disabled for the most part since dircache no longer lowers its thread's I/O priority. It existed primarily for the aforementioned configuration. Change-Id: Ia04935305397ba14df34647c8ea29c2acaea92aa
Originating from 3661581 Some build clients finding their "standard" string.h's that don't declare strlcpy? Change-Id: I50d19c7cecf5ae96ee1855f77d3c2e1f42620108
Change-Id: I99b90ab7e5b7d074b1d2d1de72267f9f2eea975b
It is trivial to obtain all required information from the allocated handles without maintaining global indexes. In fact, it is less complicated and increases general thread safety. Other miscellaneous changes (some are nice to do at this time due to required alterations, with some particularly more relevant than others): * Handle value 0 will no longer be returned as a valid handle but all failures will still return a negative value. Creates consistency with buflib and removes the need to explicitly initialize them. * Linking a new handle is delayed until explicitly added by the code that called add_handle, keeping it invisible until every operation succeeds, which is safer thread-wise. If anything fails, the handle itself may just be abandoned rather than reqiring it be freed. * Dump the special handling to slow buffering when the PCM buffer is low that calls PCM buffer functions. It doesn't seem to help much of anything these days and it's a bit of a nasty hack to directly tie those bits together. It can of course be put back (again!) if there really is a need for it. * Make data waiters ping the buffering thread more than just once if the request is taking too long. Somehow I figured out how the requests could get forgotten about but can't remember why months later after making the change in my branch. :-) * Neaten up some code by using (inline) functions and packing down parameters; remember handle allocation and movement attributes in the handle itself rather than figuring it out each time they're needed. Change-Id: Ibf863370da3dd805132fc135e0ad104953365183 Reviewed-on: http://gerrit.rockbox.org/764 Reviewed-by: Michael Sevakis <jethead71@rockbox.org> Tested: Michael Sevakis <jethead71@rockbox.org>
Change-Id: Ie7b04ecf3b3535e0ed45a6e0e8d81af89e38378e
Change-Id: I2072c355f05b6e709a5c179512bc2b71756163a5
...by default where they would be interpreted as valid but not actually be which would cause calls to buffering while it was not initialized. Add BUFFER_EVENT_BUFFER_RESET to inform users of buffering that the buffer is being reinitialized. Basically, this wraps all the functionality being provided by three events (...START_PLAYBACK, RECORDING_EVENT_START, RECORDING_EVENT_STOP) into one for radioart.c, the only user of those events (perhaps remove them?) and closes some loopholes. Change-Id: I99ec46b9b5fb4e36605db5944c60ed986163db3a