Let me start off by saying that I'm well aware that I'm a masochist, and that this will be a large, potentially painful undertaking. But hey, what with graduating college, and finding a stable job out of the way, I need something to keep my life interesting.

I really like the Hijack project, and it's really cool. However, a lot of the stuff it does is really more suited to userspace than kernel space. It also does a lot of work in kernel space to modify the behavior of a userland app, whent the "proper" way to do it would be to simply change the userland app. Now, given the constraints of an open source kernel with a closed source userland app, I'll agree that while it's not pretty, it's about the only way to tackle the problem. Ideally, though, we'd have an open source player app to complement the open source kernel, and a lot of these things could be done much more effectively by simply changing the player.

I haven't been able to find reference elsewhere on this board to a project like this, so... I'm planning on writing a new player app. My goal is to get something at least minimally functional up and running before releasing it, so people who want to tinker with it/add to it can have a useful baseline. Before I start, though, I want to get some feedback from the developer community of what sort of things they'd like to see in it, so I can make sure they system can accomodate the wide variety of demands it will be subjected to.

There are some services provided by the Hijack kernel which are obviously best done in kernel space, and for those sorts of things I don't want to spend the effort writing in userland what's already been done the "right" way in kernel space. The thing that jumps to mind first in this area is virtualizing the display. Letting separate apps each think they're writing to the screen makes a lot of things a lot easier. The existing scheme would need to be modified somewhat, but that's still quite a way down the road.

Having said all that, I'll outline my current thoughts on the software design:

I'm leaning towards a "plugin" oriented design, so most things will not be done by the core player app, but by separate plugins. The player app will be primarily responsible for providing a user interface (probably along the lines of the current menu interface, as it seems like a perfectly good design, plus everyone's already used to it). The player app will also be responsible for coordinating the playing of songs and, of course, pretty visuals. Note that the player app will only be coordinating these things; the actual work will be delegated to plugins. This should make it relatively easy to add support for new visuals, as well as new audio formats. Particularly, it will allow adding visuals without rebuilding the player, so poeple would be able to just drop a new visual plugin somewhere and be able to use it without rebuilding. I expect that once it's possible, there will be no shortage of visualizer plugins.

While the player will be available under the GPL, the legal status of closed source plugins will probably be a bit hazy (much like closed source loadable kernel modules), so the license will explicitly allow closed source plugins. This will ensure that closed source plugins for propritary formats are a possibility. (I don't know that anyone will want such a thing, but I'd like to keep the option open).

I want to make it easy for plugins to add menu items. There will be two versions fo this. Once will allow simply adding a menu item to invoke a function in the plugin. The second will allow plugins to provide a full subtree of the menu. This way playlists can be managed by plugins, rather than being a part of the core player.

Finally, for interactions in menus and such, I'm wanting to keep interactions separate from the physical interface, to allow easy button remappings and other sources of input.

Obviously, the player application on its own will not be a terribly useful program, so there are several plugins that will be included in the initial release:

MP3 player plugin: will handle playing MP3s.
Oversimple DSP plugin: will allow volume control, and probably that's about it for the first version.
FIID playlist plugin: will allow access to current playlists and tunes.
A few simple visuals plugins: gotta have the eye candy
Starters: A hello world plugin and a few other simple things (which will probably be the test tools I develop along the way) in order to provide a good starting template and example of how things are supposed to work.

Once the player app and the base plugins are at least minimally functional, I'll be ready to release it. I think that will provide a sufficient platform for others to start playing with it and we'll see where it goes from there.

There are some plugins that, while I'm confident I could write them, there are others here who are much more qualified than I am, and I'm guessing that once I get a basic player up and running, someone else will jump in to write them before I get to it (DSP jumps to mind).

Anyway, I'm sure there are all sorts of things I've failed to consider, so I'd love to hear everyone else's input.

-Thomee-