|
Rockbox mail archiveSubject: Re: 1 standard generic callback systemRe: 1 standard generic callback system
From: Ray Lambert <codemonkey_at_interthingy.net>
Date: Wed, 6 Jun 2007 14:02:00 -0400 (EDT) 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 >> end-of-track >> notification. > > 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 invoked. 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 using it). 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 condition.) >> (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?? :) ~ray Received on 2007-06-06 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |