Jonathan Gordon wrote:
> On 06/06/07, Ray Lambert <codemonkey_at_interthingy.net> wrote:
>> Just to add some fuel to the fire, I also implemented a callback
>> interface when I wrote my A/B repeat feature. It's defined in
>> firmware/export/audio.h and implemented in firmware/mpeg.c
>> It uses a bitmask to subscribe to events (with a single callback per
>> subscription) and a fixed-size array (sized by #define) to hold up to 10
>> registered callbacks. It supports track position updates and
> So one callback can be triggered on multiple events? or each event can
> only have one callback?
An event is defined by a single bit in a bitmask. When you register a
callback, you can OR the bits together to request multiple events. You
can also register any number of callbacks, each with their own event
bitmap. Only one event occurs at a time and the event mask is passed to
the callback. Since it's always a single event, you can test for it with
a switch() (rather than testing bits).
An event gets triggered when the code that detects (or generates) the
event calls the event dispatch func with the event mask. The list of
registered callbacks is searched and any callback with that bit set is
There's also a set of predefined return codes from callbacks that indicate
if they serviced the event or not. If the result is affirmative, the
condition that generated the event is considered to be no longer valid
and, therefore, no more callbacks are invoked. This code also gets
returned to the event generator and may modify its behaviour.
For example, for A/B repeat I needed to detect end-of-track so that I
could jump back to the A mark (A/B repeat is designed to work like a
modified single repeat mode). So, when ABR handles end-of-track it
returns a code indicating that the event was handled. Since the track is
no longer at end-of-track, it would be senseless to report that state to
other callbacks. This ultimately causes the mpeg code which normally
invokes the next track to just keep playing instead.
There are potentially some complex issues there so I kept this
implementation pretty simple for now. But it can be expanded.
One issue has to do with priority of event handling. For example, if the
song db wants to handle end-of-track events, and ABR handles it first, the
song db will never see it. I decided to handle this (for now) by
controlling who gets to register first. It would be good to localize
registrations, if possible, to simplify this. It would also be possible
to introduce priority codes and sort the list, or something like that. I
didn't want to get into that at the time I wrote it (I was the only one
Another issue is what happens when two entities want to handle the event
but one changes the state (as in the previous example; song db and ABR).
The solution is to give song db higher priority (so it sees it first) and
then have it return a code indicating that it DID NOT handle the event.
This allows ABR to see it next. Not sure if that's a lie or if the return
code is just misnamed (i.e. I didn't "handle" it, I "changed" the
>> (I've been meaning to port
>> A/B repeat to the IAudio X5, which would mean updating it to work with
>> SW codecs and custom WPSs, but I haven't been able to find the time.)
> a/b mode doesnt work on the x5? I thought i worked on all swcodec as
> long as a button has been setup for it?
As far as I know it has not been enabled. But I may have missed it. I
haven't updated my FW in many months (I run a custom build and I haven't
had time to update it; last time I tried, certain patches that I wanted
were out of sync). And I can't even double-check it right now because my
X5 is out for repair.
Speaking of which... I had to send my X5 to Cowon with Rockbox on it
(dual-boot is enabled though and I wrote instructions to use it). I
couldn't re-flash first because my charge circuit is busted and you can't
flash with external power being detected. :( I'm not worried about the
warranty because this isn't a warrany repair, but I wonder if Cowon has
gotten to see Rockbox running much?? :)
Received on 2007-06-06