First commit of buffering.[ch], based on testplugin.c

These are based on testplugin.c, with the "rb->" API calls replaced by
regular calls. The utility and threading code are removed, except for
buffering_thread(), which is still highly experimental.

bufopen: better description of the offset parameter.

Truly read the ID3 info from the files.

Call get_metadata to obtain the struct mp3entry with the file's metadata.
We need to use special functions to copy ot move the struct mp3entry because
it has pointers to an internal buffer.
The bufopen thread needs a bigger stack for this.

Tested successfully on sim and on the gigabeat.

bufread, bufgetdata: Better check for when data isn't ready.

The only case when the caller should get less data than requested is near
the end of the file. When not enough data has been buffered, the caller has
to wait.

Make the (very primitive) metadata handling use bufalloc().

Added read_metadata() which makes a few changes to the metadata that we get
from the files. The resulting buffer is then passed to bufalloc, which stores
it in the main buffer. print_metadata() becomes much simpler thanks to this.

This is a good example of how bufalloc is meant to be used.
Tested successfully on target and sim.

Add the bufalloc API call to load data from a source other than a file.

bufopen: Factor out the pre-checking.

Factored out the code that checks there is enough space to finish buffering
the current handle. It will be used again in the next commit.

buffer_handle: Remember that we closed the FD once the file is buffered.

Moved the old standalone app to testapp.c

bufopen: Add support for data types that can't wrap.

Added a new data type: TYPE_STREAM, for stream audio that can't wrap.
The only data type allowed to wrap is audio.
Now bufopen returns -2 for all cases where adding the handle failed
because of a lack of memory space.

Add a quick buffering example.

bufseek: Changed specification and improved range checking.

It makes more sense to seek within the file than within the available data,
(that would be overly complicated for the caller anyway).
Seeking to a point before the available data should now trigger a rebuffer
(required for the case of rewinding to the start of an audio track), but I
haven't tested this yet.

free_buffer: Keep h->offset in sync so we know where we are in the file.

A couple comment changes.

bufread: Make it behave correctly.

* Correct the behaviour towards the end of the file (it simply wasn't detected).
* Don't advance the buffer reading pointer.
* Don't change h->available !!

Tested successfully on target (gigabeat) and in the sim.

bufgetdata: Check that the caller isn't too greedy.

When the buffer wraps and we need to use the guard buffer to provide a complete chunk,
there is a limit to the amount of data we can provide. It's unsafe to assume we can
provide the requested amount of data.

Cosmetic improvements and lots of comments.

Don't stop filling the buffer after the first handle that needs buffering.

Use the buffering API to access snprintf and increase stack size for the bufopen thread.

A few buffer freeing and debug ouptut tweaks.

* Only free the buffer when there is data left to be buffered.
* First free buffer space from audio data, then move the metadata (more efficient).
* A few debug output improvements.

Introducing metadata in the test !

Before opening the audio files, the bufopen thread will open corresponding metadata files
from /meta/X.txt, where X is the name of the audio file. The first two lines of the file
will be displayed on the screen while the audio file is read.

Add a "type" argument to bufopen and make it capable of reserving space before opening new handles.

Instead of simply refusing to open a new handle when the current one isn't finished buffering,
we check that there is enough space for the current one to finish buffering and open the new
handle at the right place.

Also adapted buffer_handle to this.

Make free_buffer move metadata handles

We want to make metadata handles always be as close as possible to the audio data.

Make move_handle capable of moving data from the handle along with the handle struct itself.

Add a data_size argument to move_handle, to make it move a certain amount of data at the same time as the handle.
This will allow moving metadata handles easily within free_buffer.
Also updated the comment for move_handle and the move_handle calls in the linked list test.

Clear the warning

Thread behaviour changed (faster "playback").

Tightened the timings to make playback go faster and changed the buffering behaviour.
It now rebuffers and clears wasted space more often.

Tested successfully on target (gigabeat) and sim.

A bit of cleaning up.
Trimmed long lines and removed useless commented debug output.

Also stop copying if it would overwrite the next handle.

Correct and enable the disabled part of the linked list test. It now works on target too.

git-svn-id: svn://jdgordon.mine.nu/mob@60 9862a28c-4e93-4879-ac26-10afcf840a8f

Write to the handle's current position and not the buffer writing position.
Shouldn't change anything now but will prevent potential bugs.

Enable the type struct member.

Some debug output tweaks

The data_len struct member isn't needed

Don't change h->ridx when moving the handle.
This makes the output correct :)

Some fixes
* A long lasting bug in free_buffer
* We can only add a handle when the current one has finished buffering
* Some debug output changes

Add a new thread ("bufopen") that just adds files. Rename the playback thread codec thread. Fix bugs.

The bufopen thread will try adding a new file to the buffer every 8 seconds. There can now be between 0 and all the files on the buffer at the same time, which is much more interesting than only one.
The playback thread is now actually much closer to the real-life codec thread than the playback thread (though it's a very simple codec), so now is a good time to rename it.

Bugfixes:
* When adding a handle fails, close the file descriptor that was opened to get the file's size.
* When moving a handle, the alignment should be done backwards, or else we risk losing some data, and free_buffer() needs to check whether the movng succeeded.
* Before aligning the buffer write position to add a new handle, it's better to check whether we have enough space to do that.
* When we see we can't allocate enough space for the whole file, we need to make sure we take enough off the asked size, or else there might be a confusion between the empty and full states of the main buffer.

Remove a useless part that was meant to add a new file.

Add a bit more information on screen

Add some basic screen output.
The amount of data read (by the playback thread) for the current file is displayed on screen. This helps know what's happening for on-target tests (which I haven't done lately).

git-svn-id: svn://jdgordon.mine.nu/mob@57 9862a28c-4e93-4879-ac26-10afcf840a8f

Use generic file names instead of the ones I initially hard-coded, to make testing easier.

git-svn-id: svn://jdgordon.mine.nu/mob@53 9862a28c-4e93-4879-ac26-10afcf840a8f

Small cosmetic change in buffer access.
Use &buffer[idx] instead of buffer + idx.

git-svn-id: svn://jdgordon.mine.nu/mob@52 9862a28c-4e93-4879-ac26-10afcf840a8f

Fix the missing bytes bug.
the write() call can only happen when bufgetdata returns a positive value.

git-svn-id: svn://jdgordon.mine.nu/mob@51 9862a28c-4e93-4879-ac26-10afcf840a8f

Code cleanup.
Removed the outdated disabled code.

git-svn-id: svn://jdgordon.mine.nu/mob@50 9862a28c-4e93-4879-ac26-10afcf840a8f

A few changes:
* Slightly change how move_handle works to make it more practical to use.
* Change the sleep durations. This solves a problem I had where a long file would stop being buffered after less than a megabyte with error "bad file number". I think "playback" was simply too fast but this needs to be investigated.
* Turn backlight on when the plugin is finished
* The disabled code that I added is the basic beginning of having more then one file on the buffer at a time. It's not my priority right now.

There is a bug left on targets: the first two bytes (maybe not always two though) are missing on some of my test files. The others come out fine. After some tests, it seems that the buffering is ok (the first two bytes of the buffered data are correct), but at some point the bytes are lost when writing the file or reading the memory.

git-svn-id: svn://jdgordon.mine.nu/mob@49 9862a28c-4e93-4879-ac26-10afcf840a8f

trying again

git-svn-id: svn://jdgordon.mine.nu/mob@48 9862a28c-4e93-4879-ac26-10afcf840a8f

no code change, testing something with the repo

git-svn-id: svn://jdgordon.mine.nu/mob@47 9862a28c-4e93-4879-ac26-10afcf840a8f

Fix the warnings by using more appropriate types.

git-svn-id: svn://jdgordon.mine.nu/mob@46 9862a28c-4e93-4879-ac26-10afcf840a8f

It works on target !

* Increase stack size and reduce stack usage for the playback thread to prevent panic:stkov crashes on target (test on gigabeat). The files are outputted correctly.
* Make bufread() and bufgetdata() return -2 when the data for the handle isn't ready and add the check in the playback thread.

git-svn-id: svn://jdgordon.mine.nu/mob@45 9862a28c-4e93-4879-ac26-10afcf840a8f

* Add data_rem() that returns the amount of data left to buffer. This prevents the buffering thread to endlessly try to fill the buffer when nothing is available to fill it with.
* Add a remove_thread() call to end the playbck thread.
* Make the reading faster.

Now it works well on the sim: it buffers the files and reads them progressively, and the MD5sums are correct. I still have to test on target.
Currently it only has one file in the buffere at a time.

git-svn-id: svn://jdgordon.mine.nu/mob@44 9862a28c-4e93-4879-ac26-10afcf840a8f

Almost complete rework of the threading logic.
The buffering thread is in fact just there to fill the buffer at appropriate times, so there is no need for the messaging code  I added earlier.
The code in both the threads is still basic and untested, so it probably doesn't work, but I think it reflects what the threads should do.

git-svn-id: svn://jdgordon.mine.nu/mob@43 9862a28c-4e93-4879-ac26-10afcf840a8f

Better use of queue_send and trim a few long lines.

git-svn-id: svn://jdgordon.mine.nu/mob@42 9862a28c-4e93-4879-ac26-10afcf840a8f

Apply the previous change to buffering.c with a bugfix. There needs to be more changes if we want to really use the new data_len field.

git-svn-id: svn://jdgordon.mine.nu/mob@41 9862a28c-4e93-4879-ac26-10afcf840a8f

* Add a size argument to add_handle() so that it can reserve space.
* Add a data_len field to the memory_handle struct to allow easy access to the buffer space for the handle (this might not be really necessary).
* Add a queue_reply call to make the queue_send calls return a value.

git-svn-id: svn://jdgordon.mine.nu/mob@40 9862a28c-4e93-4879-ac26-10afcf840a8f

Use queue_send to (IIUC) make some calls blocking and allow them to return a value. It has to be added to the plugin API.

git-svn-id: svn://jdgordon.mine.nu/mob@39 9862a28c-4e93-4879-ac26-10afcf840a8f

Beginnings of threading.
There is a playback thread and the plugin main function will emulate the buffering thread.
The buf*() API calls post messages to the buffering thread, that will treat them in sequence.
The code compiles with a lot of warnings and still needs a lot of work. It probably wouldn't work at all but I haven't tested it.

git-svn-id: svn://jdgordon.mine.nu/mob@38 9862a28c-4e93-4879-ac26-10afcf840a8f

Apply some of the changes made to the test plugin to the standalone app.

git-svn-id: svn://jdgordon.mine.nu/mob@37 9862a28c-4e93-4879-ac26-10afcf840a8f

Use DEBUGF instead of logf and add #defines to avoid having to change all the time.
Other than that, nothing very interesting and no actual code change.

git-svn-id: svn://jdgordon.mine.nu/mob@36 9862a28c-4e93-4879-ac26-10afcf840a8f

Move the plugin to the root, as testplugin.c

git-svn-id: svn://jdgordon.mine.nu/mob@35 9862a28c-4e93-4879-ac26-10afcf840a8f

The problem on target was due to alignment issues, so add alignment checks. There might be more required.
I don't understand why, but the linked list test still fails on target because of move_handle().

git-svn-id: svn://jdgordon.mine.nu/mob@34 9862a28c-4e93-4879-ac26-10afcf840a8f

A few minor changes to buffering.c and add the plugin version.

git-svn-id: svn://jdgordon.mine.nu/mob@33 9862a28c-4e93-4879-ac26-10afcf840a8f

A bit more maintenance.

git-svn-id: svn://jdgordon.mine.nu/mob@32 9862a28c-4e93-4879-ac26-10afcf840a8f

* Moved some helpers (definitions of rockbox macros) to helpers.h.
* Replaced printf calls by DEBUGF for future porting to rockbox code.
* Renamed h->buf_idx to h->ridx and introduced h->widx, mainly to allow buffering any handle, not just the current one.
* Moved the memory_handle struct into buffering.c because it's not supposed to be exported.

git-svn-id: svn://jdgordon.mine.nu/mob@31 9862a28c-4e93-4879-ac26-10afcf840a8f

Add an error check to bufseek() and add bufadvance() to seek relatively to the current buf_idx.

git-svn-id: svn://jdgordon.mine.nu/mob@30 9862a28c-4e93-4879-ac26-10afcf840a8f

Take the "size" argument into account in bufgetdata(), using the guard buffer if needed to ensure enough data is provided. The main() now reads files in chunks of the size of the guard buffer, but without using the guard buffer. This hopefully simulates codec behaviour accurately.

git-svn-id: svn://jdgordon.mine.nu/mob@29 9862a28c-4e93-4879-ac26-10afcf840a8f

* Implement bufgetdata() and change the main() so it uses it.
* Change free_buffer to accept a handle_id as argument so it can be used on any handle.
* A few other minor changes

git-svn-id: svn://jdgordon.mine.nu/mob@28 9862a28c-4e93-4879-ac26-10afcf840a8f

Nico please read unless there is another commit from me today.
random thoughts on a safe area for the MoB

git-svn-id: svn://jdgordon.mine.nu/mob@27 9862a28c-4e93-4879-ac26-10afcf840a8f

Correct the comment for free_buffer now that we know it works well, and make it display the buffer status when it finishes.

git-svn-id: svn://jdgordon.mine.nu/mob@26 9862a28c-4e93-4879-ac26-10afcf840a8f

first woops commit :D

git-svn-id: svn://jdgordon.mine.nu/mob@25 9862a28c-4e93-4879-ac26-10afcf840a8f

fix caching

git-svn-id: svn://jdgordon.mine.nu/mob@24 9862a28c-4e93-4879-ac26-10afcf840a8f

Disable the limiting to 5 reads in the playback part. A file bigger than the buffer is now outputted correctly.

git-svn-id: svn://jdgordon.mine.nu/mob@23 9862a28c-4e93-4879-ac26-10afcf840a8f

simulate the playback thread a bit better
move the first handle to fre up space when a certain amount is wasted
almost have working large files

git-svn-id: svn://jdgordon.mine.nu/mob@22 9862a28c-4e93-4879-ac26-10afcf840a8f

Some improvements to the main().

git-svn-id: svn://jdgordon.mine.nu/mob@21 9862a28c-4e93-4879-ac26-10afcf840a8f

Attempt to implement buffer freeing. Something is wrong somewhere with the moving, but I couldn't figure out what. Disabled the caching in case it is interfering.
Added a function to graphically display the status of the ring buffer.
More details later, I have to go.

git-svn-id: svn://jdgordon.mine.nu/mob@20 9862a28c-4e93-4879-ac26-10afcf840a8f

add some note-to-self comments

git-svn-id: svn://jdgordon.mine.nu/mob@19 9862a28c-4e93-4879-ac26-10afcf840a8f

remove dead code

git-svn-id: svn://jdgordon.mine.nu/mob@18 9862a28c-4e93-4879-ac26-10afcf840a8f

more main() cleanup. playback handles unbuffered files properly

git-svn-id: svn://jdgordon.mine.nu/mob@17 9862a28c-4e93-4879-ac26-10afcf840a8f

add -Wall to the makfile and fix the warnings.

git-svn-id: svn://jdgordon.mine.nu/mob@16 9862a28c-4e93-4879-ac26-10afcf840a8f

the "buffering thread" now uses the LL to buffer data instead of
remembering handle id's, which should be more closely how the final
thread will work

git-svn-id: svn://jdgordon.mine.nu/mob@15 9862a28c-4e93-4879-ac26-10afcf840a8f

the 3rd param to open is an octal value, not decimal :p

git-svn-id: svn://jdgordon.mine.nu/mob@14 9862a28c-4e93-4879-ac26-10afcf840a8f

Add a really simple Makefile becuase im lazy

git-svn-id: svn://jdgordon.mine.nu/mob@13 9862a28c-4e93-4879-ac26-10afcf840a8f

* Add move_handle().
* More checking in LL functions.
* Add a LL test suite to make sure everything works fine.

git-svn-id: svn://jdgordon.mine.nu/mob@12 9862a28c-4e93-4879-ac26-10afcf840a8f

Rename aux.[ch] because the name "aux" is forbidden on windows.

git-svn-id: svn://jdgordon.mine.nu/mob@11 9862a28c-4e93-4879-ac26-10afcf840a8f

Fixed the wrppaing bug in bufread(). Now all my 4 test files come out right :)

git-svn-id: svn://jdgordon.mine.nu/mob@10 9862a28c-4e93-4879-ac26-10afcf840a8f

implement bufread() and better testing. checking md5sum of the outputted
files shows that there is a bug when the file wraps the end.

git-svn-id: svn://jdgordon.mine.nu/mob@9 9862a28c-4e93-4879-ac26-10afcf840a8f

prevent 2 segfaults. slight error checking imporvemnt.
Add my code to do a proper test of the system. It looks like it buffers
correctly. have to implement proper bufread() to find out for sure.
./a.out <file list> to test

git-svn-id: svn://jdgordon.mine.nu/mob@8 9862a28c-4e93-4879-ac26-10afcf840a8f

add a quick readme explaining what this file is

git-svn-id: svn://jdgordon.mine.nu/mob@7 9862a28c-4e93-4879-ac26-10afcf840a8f

buffer_handle improvement to make it accomodate several calls.
I changed the main() to suit my test: I give it 3 files of ~35 MB so the third isn't completely buffered at first and after unbuffering the first two we can finish buffering it and it wraps around the end of the buffer.

git-svn-id: svn://jdgordon.mine.nu/mob@6 9862a28c-4e93-4879-ac26-10afcf840a8f

Added bufseek() and changed the handle struct slightly.

git-svn-id: svn://jdgordon.mine.nu/mob@5 9862a28c-4e93-4879-ac26-10afcf840a8f

add some simple caching to find_handle()

git-svn-id: svn://jdgordon.mine.nu/mob@4 9862a28c-4e93-4879-ac26-10afcf840a8f

Adding my old code which might prove useful later... (or not :p)

git-svn-id: svn://jdgordon.mine.nu/mob@3 9862a28c-4e93-4879-ac26-10afcf840a8f

test

git-svn-id: svn://jdgordon.mine.nu/mob@2 9862a28c-4e93-4879-ac26-10afcf840a8f

Initial commit of my work.

git-svn-id: svn://jdgordon.mine.nu/mob@1 9862a28c-4e93-4879-ac26-10afcf840a8f