The buffer_offset paramter of audio_init_recording() is removed as it
was unused in both implementations.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30310 a1c6a512-1295-4272-9138-f99709370657
Namely, introduce buffer_get_buffer() and buffer_release_buffer().
buffer_get_buffer() aquires all available and grabs a lock, attempting to
call buffer_alloc() or buffer_get_buffer() while this lock is locked will cause
a panicf() (doesn't actually happen, but is for debugging purpose).
buffer_release_buffer() unlocks that lock and can additionally increment the
audiobuf buffer to make an allocation. Pass 0 to only unlock if buffer was
used temporarily only.
buffer_available() is a replacement function to query audiobuflen, i.e. what's
left in the buffer.
Buffer init is moved up in the init chain and handles ipodvideo64mb internally.
Further changes happened to mp3data.c and talk.c as to not call the above API
functions, but get the buffer from callers. The caller is the audio system
which has the buffer lock while mp3data.c and talk mess with the buffer.
mpeg.c now implements some buffer related functions of playback.h, especially
audio_get_buffer(), allowing to reduce #ifdef hell a tiny bit.
audiobuf and audiobufend are local to buffer.c now.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30308 a1c6a512-1295-4272-9138-f99709370657
also remove the audio_filename from the cuesheet struct as its useless
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@21982 a1c6a512-1295-4272-9138-f99709370657
swcodec: search for a .cue during buffering (with the possibility of adding embedded cuesheets later)
hwcodec: search for a .cue when the id3 info for the current track is requested for the first time (disk should be spining so non issue)
major beenfit from this is simplofy cuesheet handling code a bit... if mp3entry.cuesheet != NULL then there is a valid cuesheet.. no need to worry about if its enabled and preloaded.
There is the possibility of putting the next/prev subtrack handling inside the playback code (as well as the id3 updating stuff (see FS#9789 for more info), but thats probably not a good idea.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@21978 a1c6a512-1295-4272-9138-f99709370657
* Move strncpy() from core to the pluginlib
* Introduce strlcpy() and use that instead in most places (use memcpy in a few) in core and some plugins
* Drop strncpy() from the codec api as no codec used it
* Bump codec and plugin api versions
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@21863 a1c6a512-1295-4272-9138-f99709370657
* Use events to notify things when the track has changed instead of the nasty has_track_changed()
* Event for when the mp3entry for the next track is avilable (which allows alot more tags to be static which means less redrawing in the WPS)
* virtually guarentee that the mp3entry sturct returned by audio_current/next_track() is going to be valid for the duration of the current track. The only time it wont be now is during the time between the codec finishing the previous track and the next track actually starting (~2s), but this is not an issue as long as it is called again when the TRACK_CHANGED event happens (or just use the pointer that gives)
It is still possible to confuse the WPS with the next tracks id3 info being displayed but this should fix itself up faster than it used to (and be harder to do)
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@20633 a1c6a512-1295-4272-9138-f99709370657
This should be a good first step to allow multi-driver targets, like the Elio (ATA/SD), or the D2 (NAND/SD).
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@18960 a1c6a512-1295-4272-9138-f99709370657
