I just stumbled on this thread today.
good to see other people here are not afraid of Java...
I've been working on a java media player for a few years (off and on). I started with Javazoom components (google javazoom) for the player but now that java.media is out I'm looking into that.
Originally I started with a music player like yours but I'm now looking at including video and an image viewer, as well as add-ins for other media players (think Sirius/XM satellite, HD Radio, etc...)
A few weeks ago I started a sourceforge.net project for this (JMobile Media Player), still need to upload the source but if you're interested in collaborating on this project let me know. or go to http://sourceforge.net/projects/jmmplayer/
The idea behind this is to focus on a mobile environment (large buttons with minimal input)
and cross platform compatible.
It's also designed to work with a mobile OS (like LinuxICE and NGhost2) where the OS is the front end and the player would be another app.
and for all the Java-bashers, there is no noticeable lag in performance, it just works.
I really haven't done much lower level coding, just using components already developed.
like javazoom and jlgui
So if djk7 turns out to solve a bunch of media problems, it shouldn't be too difficult to integrate them into my media player.
Basically my main focus is creating a CarPC/UMPC friendly platform independent media player.
I haven't looked at jdk7 much yet, any insight on what new muscle they are adding, other than JMF?
Nah, it won't be diffficult to transition to the new API, whatever it turns out to be. My concern was wasting time trying to push the envelope when Sun is already pushing it for me.
There is a blog keeping track of the jdk 7 features: http://tech.puredanger.com/java7/.
Sound can be done in cross platform fashion using existing APIs, but not where DRM is involved. Video is the other hurdle, and there is no good all-in-one solution that I am aware of. For example, JVLC could provide the cross platform video, but the performance of certain files on Windows is downright awful. Example: high definition WMV files. Also, the future of JVLC is not clear.
Then, there is the enormous task of building a mapping / route planning / GPS solution. Remember, most maps are copyrighted or online only, and you have to be able to do the gps functions without an internet connection or else it's worthless.
For GPS I had looked at using the Tiger line files (or new shape files that they converted to) as the map data. Shape files are the easiest to acquire for little or no price and can be edited easy enough for custom maps.
There were a few API's for viewing shape files in java but I haven't looked into them in a while.
Google "Java GIS" (GIS = Graphical Information System)
The problem with the Tiger data is it's accuracy and it's lac of POI's and it's US only.
Though they did just release a new dataset of shape files
This is what a lot of the US GPS map data is created from, with a lot of cosmetic surgery to make the data more accurate.
Thumbs up for the effort, we need more Java based frontends.
I'm currently working on a car system myself but it more like the whole package than a frontend (unless you consider Xorg a backend ^^). I started with a complete modular design but dropped that for 2 reasons:
1. I want to tightly integrate all components: if the navigation speaks, turn down the music - if a call comes in, pause the music etc.
2. Design speed: the original design to do everything modular became too damn complicated without even coding a single line. By the time I have a finished piece of software I probably have ideas to refactor everything into a more generic framework.
I am looking for 3 things in my car pc: music, navigation and phone control. All the other fancy features I see around are possibly awesome for version 2.0 (if I ever get there) but to replace my current head unit + car kit + TomTom, those are the three items I need the most.
Enough about my little project. I'm very anxious to see how you get stuff solved as I'm running into much of the same problems. One tip to get awesome multi-media support: use the XineLib Java bindings. The downside is that you will require linux to run on unless you tie it together with cygwin or something...
And a final kick to the people who hate Java: I'm using openGL accelerated animations, using Mesa (software rendering as I broke native openGL atm - aka slow *** 3D) I use ~40% CPU on a 2.6GHz Pentium 4 rendering between 350 and 500 fps. Yes I know thats insane so usually I cap it off to 25 fps which then draws (including Xine playback) 3% - 5% CPU. I would say thats pretty respectable (for 800x600 rendering 25 components with animation and alpha layers).
I'd love to :-)
Right now I'm working on the final screens for the music player. I'm waiting for somebody to help me figure out how to access the visualizer from xinelib.
As soon as I got those 2 points sorted I'll make a demo video and put it up on Youtube. I haven't decided if I'm gonna release the code or not but currently only half the classes are documented so it won't do anybody any good either ^-^.
I'll keep you posted on my progress.
Edit: right now I use custom rendering for the components (to get the translucent effects) but I don't use 'real' skinning: only the position and size of components are determined from XML files (I had chosen for the same percentage based positioning I saw somebody suggest somewhere when I found this thread). I'm thinking about using SVG based skins as they would resize nicely for each resolution and ratio. Just another item on my todo list that is slowing me down ;-)
I think that's pretty much the price of admission for any front end. Music (sans DRM) is easy. Phone control is a little harder, but possible. The darned navigation is very difficult, because all the maps are copyrighted, and existing nav apps / sdks are not cross platform, so you can't just integrate one. Sure, you can do a mashup, but then everyone using it would need mobile internet, and I don't think most of us have that.Originally Posted by cyberwizzard
If it ties me to an OS, there's no point- and tying it together with cygwin would be a support nightmare. I don't want to release anything my grandma couldn't install.Originally Posted by cyberwizzard
1: Most people that come here know how to strip an OS and install dependencies, if Xine would be a dependency, people should be able to tackle it. Even better, if it is actually linked properly it would just sit in a directory in the archive or installer inside the application directory. No installers, no dll's, no copying certain versions of obscure .ocx files - nothing of the sorts.
If (and note the 'if' as I have to test if it will work on Xine as well) thats the case, its more likely that grandma can install Ubuntu and my application (with everything on board) than a random Windows frontend which requires Media Player X, Routing Software Y and bluetooth dongle Z from manufacturer A.
2. I target linux at the moment as I have zero confidence in Windows XP in my car. I am a master student computer science with years of experience of wrecking computers and Redmond and me don't come along very well. Tbh, I'd rather put Vista on a car pc than XP but my main concern is start up times and frankly, Windows is just slow... But each his own ofcourse and the lucky Windows users can opt for tools like StreetDeck - which looks pretty awesome :-0
But as I stated, Windows can be supported later on by means of Cygwin or a simple switch of the backend (As long as the API doesn't change, the application won't know which program is playing the music anyway).