Rockbox mail archiveSubject: Re: few remaining issues for memory playback, plugin API
Re: few remaining issues for memory playback, plugin API
From: [IDC]Dragon <idc-dragon_at_gmx.de>
Date: Mon, 12 Jan 2004 09:03:48 +0100 (MET)
> [IDC]Dragon wrote:
> > I have prepared a new function pair mp3_get_playtime() /
> > mp3_reset_playtime() to query the playback time instead, but it is not
> > yet.
> What is the purpose of reset_playtime()? Doesn't the mp3 code reset it
> automatically for each track?
The playtime is updated in the playback_tick() I'd like to get rid of, and
is reset on a track change. But we don't need to update the playtime with each
DMA transfer, this is overhead. Instead it can be queried with
mp3_get_playtime() where needed. This funtion takes the paused time into account, but
doessn't know about tracks. So it has a function to reset.
But you indirectly point me to the fact that this function may rather belong
to the mpeg.c code. We can do the pause and reset-on-trackchange business
there. External players can keep their own time if they have to, it's not
really a function of the (low level) sink.
> > These issues could be solved with wrapper code for plugin playback, such
> > that the volume is set again when a plugin wants to play, and set a flag
> > that prevents calling of playback_tick(). But I don't like that too
> > don't want to create special cases.
> I think a wrapper function for mp3 playback from a plugin is reasonable.
My intention was to give direct access to the unmodified function, but well.
If we restore the volume for plugin playback, there is still the question of
how the plugin can increse/decrease that if it doesn't know the original
value. What's your position to making the config available? Or is there another
way to read the volume?
-- +++ GMX - die erste Adresse für Mail, Message, More +++ Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.netReceived on 2004-01-12