Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Playback Engine Rework - The basic rundown

Re: Playback Engine Rework - The basic rundown

From: Michael Sevakis <jethead71_at_sbcglobal.net>
Date: Tue, 10 May 2011 14:45:56 -0400

----- Original Message -----
From: "Jonathan Gordon" <jdgordy_at_gmail.com>
To: "Michael Sevakis" <jethead71_at_sbcglobal.net>; "Rockbox development"
<rockbox-dev_at_cool.haxx.se>
Sent: Tuesday, May 10, 2011 1:57 AM
Subject: Re: Playback Engine Rework - The basic rundown

> I cant remember if there is a generic "redraw the damn ui" event or
> not. If there isnt I see no reason why an event to say "current track
> has been updated" couldnt be added.
> There is always going to be the possibility that AA will be ready well
> after the track has started and we want the WPS/SBS to know about that

Not in playback. It treats the track change event as the full update event
but those come often when only metadata is ready and the remaining handles
have yet to load. It's worth repeating here (and other things I said in IRC)
that perhaps just loading all handles in one operation could work. I don't
know why the load split at metadata since a track doesn't actually play
until the audio handle is created, which is the last handle for a group of
track handles. I left certain things as they were in the old code for now
and the reasons for certain things can be rediscovered later on.

In allocated order:
<id3||[cuesheet|][album art|]*[codec|]audio>

As of now, WPS is often informed at the "||". Sometimes all handles will
have been allocated before the track is reached (if it was an
already-buffered track, for instance). When buffering reports "id3" as
complete, then the remaining handles are done. If the buffer fills, whatever
handles didn't fit are completed later in the case of packet audio or just
redone in the case of atomic audio (because that can be allocated with
greater likelyhood from the start of the buffer because it cannot wrap).

Cuesheets and album art are loaded directly on the audio thread as well as
being loaded in the second half.

I supposed "codec" and after are not much of concern for WPS, just the first
three of which the majority are done by audio itself. The event must come
when the track is the user track, not the decoding track, and it has loaded
those handles. Place it at the "*".

Well, that's part of how this works internally. Consider it documentation.
:-)

Mike
Received on 2011-05-10


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa