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-

There is already a (somewhat dead) 3rd party player based on the Rio Receiver. See here. This may save you some time.

Cool I hadn't seen that. When I start getting into the nitty gritty, I'll go through that code and see what's of use. For now, though, I want to get a good game plan laid out before I get too far into the project.

I'd be willing to help with some coding if needed. I'm a C/C++ developer by trade. One thing I'd would really want to see in the new player is some sort of 'FAVORITES' display, which display the last 4 or 5 played album, and songs. Since the current player makes it quite tedious to get around. Also, I really feel that the original developers really blew it in terms of useability in a moving car while driving. Why, oh why do they scroll horizonontally? That's such a poor idea, since it takes much longer to show the same info that could be displayed vertically, and it takes more of your attention away from driving. And if you have a lot of playlists, like me, it takes forever to scroll through them. There should be an option to allow either horizontal or vertical scrolling of playlist selection. That way everyone can be happy.

I would love to see a fully customizable player app.

Also, I really feel that the original developers really blew it in terms of useability in a moving car while driving.


That's fighting talk...

I don't honestly feel the same way. It does take a while to understand the best way to organise your playlists, and to get the most out of the player...but if you want to put 'your money where your mouth is' so to speak, I'm sure that you'll soon appreciate just how good the players UI is.

Good luck

...it reminds me the "Hijack scrolling vertically" release...

This is a great idea. The one improvement that I'd love to see is the ability to display double-byte character sets. About half of my collection is not english, and while the playlist titles are english, the song titles are not. The player just displays garbage for these songs.

Good luck with the project!

I'm happy to help out in any way I can. Quite happy to do some beta testing, I've got two players, and I'm happy to blow one up (so to speak).
Perhaps the single best feature you could include up front for many people would be playing ogg encoded files. Imagine having a completely open source player! However, don't let creature feap hold you up, and please let us know how you are doing!

I'll admit I haven't poked in a while, but I though rioplay could do that now.

I wonder how hard it would be to add real visualizations to rioplay. Hmmm.

I wonder how hard it would be to add real visualizations to rioplay. Hmmm.

If you're talking about empeg-quality visualizations, I hope you're a hardcore ARM assembly guru!

I'd settle for one of scope or spectral events. I know zero ARM assembly, and am only slightly better at x86 (and not much better than that on Sparc).

I'm sure I'll hate myself, and I should find better things to do with my time.

I wish you all the luck and I would be more then happy to test it and report bugs. OGG support is *the* main feature request at the moment. When the ball does start rolling, make sure you practice the "release early, release often" method. Upgrading hijack at least three times a week was so much fun last winter.

later,
ajay

Hi Elessar
Well done on taking this initiative. I wish you best of luck with it. I would love to contribute - however, I don't seem to be able to find much free time at the moment, so I won't promise anything. I am a C programmer by trade, and like yourself a recent college graduate, but with no empeg and very little linux programming experience.
Perhaps I can help by looking over any design docs or code you produce, like an informal technical review or something. I find that that often helps to eliminate a lot of bugs without the pain of real-time debugging.
One thought I had on the design is that there could be a parent app, like an application launcher which could be used to open and close apps such as the player app or gpsapp or emptriv or whatever, and to switch between them - sort of like a simple window manager I guess. That way, everything becomes an individual app, running as a child of the parent app, and the player app doesn't own the empeg when its running. I imagine it would make things easier for developing other non-player apps, although I don't really know that since I haven't tried developing one myself.

-Dan