A new mplayer front end is hitting the scene: Aura Media Player

skottish · 2009-09-14 00:30:11

I'm always glad to see new projects. I personally just use MPlayer launched from the CLI, but I wish you the best of luck with this.

Moving to Community Contributions.

And to everyone: don't turn this into some anti-Java thread. It's a total waste of everyone's time.

thecombjelly · 2009-09-14 03:18:18

A rundown of planned or currently worked on features...

-A media library/collection designed for ease of use for videos and music
-Audio visualizations (currently somewhat working)
-Meta info updater (planned to be quite similar to what amarok has)
-Integration with network protocols for control and plasmoids/other widgets
-OSD (similar to amarok)
-Video playback optimizations (choosing the best mplayer options for best performance or quality and comprehensive intuitive control of mplayer options)
-Alternative backend support (phonon first probably)
-Tray Icon Tooltip to include much more information
-Extensive plugin system. Currently a framework already exists, a shoutcast plugin for radio streams exists, a jamendo one hopefully soon.
...probably more I'm not thinking of atm. also we have an extremely primitive website. auramp.org

Last edited by thecombjelly (2009-09-14 03:18:53)

Ranguvar · 2009-09-14 03:40:37

After a more in-depth look...

This may be the best mplayer frontend I've ever seen o.O

Excellent work, and thanks!!

DeeCodeUh · 2009-09-14 13:29:56

Ranguvar wrote:

After a more in-depth look...
This may be the best mplayer frontend I've ever seen o.O
Excellent work, and thanks!!

And we're working every day to make it even better than itself.
You will surely see many new updates and features in the future.
This hasn't even been officially released yet.

theringmaster · 2009-09-14 13:34:45

why QT though, us gtk users don't want to mix our toolkits around.

thecombjelly · 2009-09-14 14:14:25

Ranguvar wrote:

This may be the best mplayer frontend I've ever seen o.O

Thanks! That is our aim!

thecombjelly · 2009-09-14 14:20:14

theringmaster wrote:

why QT though, us gtk users don't want to mix our toolkits around.

Sorry but QT was chosen. Mixing toolkits isn't that kind of a given? Seems frivolous to me to qualm about mixing toolkits. I think the competition between QT and gtk is good and we just happen to of chosen QT. (Originally we used swt which binds through gtk on linux I believe... But we had quite a few cross platform issues with swt that we didn't have with QT.)

I think if you put a little effort in you can actually make gtk and QT look and behave quite similarly. Please though, let's not argue about widgeting toolkits, QT is what we chose.

moljac024 · 2009-09-14 15:17:47

theringmaster wrote:

why QT though, us gtk users don't want to mix our toolkits around.

I prefer gtk too, but you do know that you can make qt look the same as gtk ? It's just a few clicks away from qtconfig.
Now SMplayer, VLC, Virtualbox etc. look just like any other gtk application...

Last edited by moljac024 (2009-09-14 15:18:52)

sakrag · 2009-09-14 20:30:56

Hi, I'm a core developer for AuraMP as well. I actually started the project (so the decision to use Java you can blame me for). Im surprised by how much interest is being generated through this forum. We still have a quite a bit to do before we create an official release such as adding a lot of the configuration options to the UI, sorting out some bugs, and making some of the features our team less commonly use work correctly (DVDNAV, CDDB Retrieval, etc). The goal of this project is simple: I believe MPlayer is the best media player I have ever used as far as performance and quality of video go however all the other front ends I have seen lack the ability to customize what I believe are some of MPlayers best features (such as not only what filters to use, but the ability to customize the actual order of the filter chain). So the goal is to provide this functionality in an easy to use, cross platform, front end. Admittedly Arch is not my preferred linux distro, thus why I have not yet posted here, however I believe in supporting as many platforms as possible to give the end user freedom of choice. This is why I originally chose Java as the language for the project. It greatly facilitates the crossplatform goal.

I have been wondering if Java was really the correct choice now. Java performs very well as far as CPU time (despite the stigma many people associate with Java), in benchmarks outperforming most other interpreted languages and almost paralleling the speed of native C++. However one disadvantage of Java is its large memory overhead which is now becoming more and more apparent in AuraMP. The problem arises due to the crossplatform nature of Java. In order to guarantee the size of primitives in java, more native memory than needed may be allocated. An example of this is a boolean allocated in a 64 bit JVM will at minimum consume 32 bits of heap space or 64 bits of stack space while in native C, a bool can be allocated in 8 bits heap or stack. This is becoming a large issue as on 64 bit JVM's, AuraMP idles at over 100MB of ram.

The project has slowed down quite a bit over the past year as I have been very busy with both work and school. We would appreciate any help from anyone else who would like to participate in development. We are also looking for developers knowledgeable with Mac to help bring a Mac release of AuraMP as most of us have a severe dislike with development on Macs. Also, I really appreciate everyone testing it out and providing feedback. It gives me a reason to want to continue working on the project and helps determine what others would like to see in the project.

Some of the features we plan on implementing down the road for a version 2 include things such as a full media library to expand on our simple playlist, A flexible plugin system (already in the works) to provide a way to add platform dependent functionality to AuraMP easily (eg: shell hooks) as well as interfacing with popular services (shoutcast, imdb, etc), tv tuner support, and audio visualizations. Tv tuner support is one feature I have not yet seen in any MPlayer frontend that I really would enjoy. It makes me sad to say that the best tv tuner application I have used is Windows Media Center which still performs horribly and unfortunately isn't free. Visualizations also may capture some interest as most people know that MPlayer itself is not capable of audio visualizations but we have an idea of how we can do it and already a somewhat working prototype.

The startup time seems to be a large complaint. I am lucky enough to have a rather powerful machine and don't notice it much so sometimes I forget about things such as that. I will look into what can be done about it. Most of the time is not spent connecting to the database as someone mentioned earlier (this is actually negligable compared to most of the initialization tasks) but rather its the allocation of native resources used by QT Jambi that takes the most time. Right now I am thinking we could overcome this be delaying the actual construction of the remaining tabs until the main window is already visible and create the remaining tabs as a background task.

I personally just use MPlayer launched from the CLI

I have seen many comments along this. That is quite alright, I even still launch MPlayer from CLI for many things. This front end though is intended as more of a heavy weight application to provide an easy way to use and configure MPlayer features that may be complicated or time consuming via CLI.

don't turn this into some anti-Java thread. It's a total waste of everyone's time.

It can be quite good to discuss the flaws of Java as long as the points are not just opinions and can be explained/demonstrated. As I said even above, I am now debating converting the project to C or C++ though I have not yet had enough reason to do so. If there are any experienced developers that wish to add to the argument for or against java, please do so. You may actually change my mind.

Crows · 2009-09-14 20:36:32

As far as the GTK/QT debate goes - you can make QT look like GTK in a few seconds. The other way around? Not so easy. I've got no problem mixing toolkits as long as that doesn't involve loading half of KDE/GNOME as well.

On-topic: I've been pretty happy with gnome-mplayer since I started using Linux, but this certainly looks interesting. Maybe once you've worked out a few more kinks I'll take a look. Best of luck.

EDIT: Just noticed the possible C/C++ switch. I've not problem with Java myself, but I can fairly confidently say that you will attract more users/developers if you switch to one of them. Still, your choice.

Last edited by Crows (2009-09-14 20:40:59)

moljac024 · 2009-09-14 21:08:16

Crows wrote:

As far as the GTK/QT debate goes - you can make QT look like GTK in a few seconds. The other way around? Not so easy.

So find a good gtk theme and make qt match it, even if you use mostly qt apps. Qt themes are uglier anyway IMO

sakrag · 2009-09-14 22:22:32

As far as GTK/QT goes, I strongly doubt we will be switching from QT. I have used many widget toolkits and I have to say that QT is by far the most elegantly simple yet powerful widget toolkit I have ever used. I havn't done a whole lot with GTK directly (though I have used swt which uses gtk on unix), but I have looked at GTK code and read through documentation and it just doesnt appeal to me as much as QT. I also as a user strongly prefer the KDE desktop environment to Gnome and QT based applications to GTK. GTK applications (though I have no real proof, its only my opinion from experience) seem to perform slightly worse than QT and the designs of some of the more complex GTK widgets don't feel as intuitive to me as their QT equivalents. QT also from what I have seen is much better at handling cross platform situations (Most of my GTK apps on linux behave or look slightly different on windows). The QT forms designer is also a very easy to use visual designer. We have used it for about half of AuraMP's user interface. For those of you who do use Gnome or other DE's, we wont include anything KDE specific, everything AuraMP is using should only require QT and some Jambi references.

thecombjelly · 2009-09-14 22:40:00

sakrag wrote:

The project has slowed down quite a bit over the past year as I have been very busy with both work and school. We would appreciate any help from anyone else who would like to participate in development.

All three of the developers currently active are going to school full time during the year and working part time. So this goes for all of us...

Also, we would be highly interested in some graphic design work as we haven't had anyone permanently contributing in that area.

skottish · 2009-09-15 00:38:08

sakrag wrote:

However one disadvantage of Java is its large memory overhead which is now becoming more and more apparent in AuraMP. The problem arises due to the crossplatform nature of Java. In order to guarantee the size of primitives in java, more native memory than needed may be allocated. An example of this is a boolean allocated in a 64 bit JVM will at minimum consume 32 bits of heap space or 64 bits of stack space while in native C, a bool can be allocated in 8 bits heap or stack. This is becoming a large issue as on 64 bit JVM's, AuraMP idles at over 100MB of ram.

I'm not a Java coder nor am I an expert in the subject, but I believe that there's another reason that the heap size is so large: performance. I've been able to reproduce claims of Haskell coders that in some cases simply increasing the heap size dramatically improves the results in the Compiler Shootout. Java by default, as you already know, uses a substantial amount of memory for heap space where Haskell is very conservative by default.

wantilles · 2009-09-15 08:18:32

DeeCodeUh wrote:

A new mplayer front end is being released soon, it has been in the development for over 4 years now.
It's based on Java and QT, and has an innovative interface by using tabs instead of extra windows.
Go ahead and install it and let me know what you think if you could.
I'd really like to get some people noticing that this exists, because it really deserves more attention than it's getting.
http://aur.archlinux.org/packages.php?ID=24962

1. Java? -> There is nothing slower, bulkier, buggier, and less responsive than Java. Thank you -> but no.

2. Why do we need another mplayer frontend?

3. What better things does it have to offer than the already excellent smplayer?

bangkok_manouel · 2009-09-15 08:29:36

if you have the "already excellent smplayer" it's because someone, some day, thought we might need another mplayer frontend.

DeeCodeUh · 2009-09-15 13:55:27

wantilles wrote:

1. Java? -> There is nothing slower, bulkier, buggier, and less responsive than Java. Thank you -> but no.
2. Why do we need another mplayer frontend?
3. What better things does it have to offer than the already excellent smplayer?

1. There is nothing more prejudiced than what you just said. Why don't you try this 30MB download before you shove it aside due to prejudice? You will be surprised.

2. This isn't just another mplayer frontend. This is in many people's opinion the best mplayer frontend that has ever been created, and it hasn't even been officially released yet.

3. I'm not even going to go through the extensive list.. just try it.

thecombjelly · 2009-09-15 13:57:30

wantilles wrote:

DeeCodeUh wrote:
A new mplayer front end is being released soon, it has been in the development for over 4 years now.
It's based on Java and QT, and has an innovative interface by using tabs instead of extra windows.
Go ahead and install it and let me know what you think if you could.
I'd really like to get some people noticing that this exists, because it really deserves more attention than it's getting.
http://aur.archlinux.org/packages.php?ID=24962
3. What better things does it have to offer than the already excellent smplayer?

My favorite would be the playlist. Smplayer's playlist is quite primitive in my opinion. Our playlist will also soon incorporate a media collection similar to amarok's of which smplayer does not have. ...Hence why I've been the one developing auramp's playlist...

thecombjelly · 2009-09-15 14:16:18

wantilles wrote:

DeeCodeUh wrote:
A new mplayer front end is being released soon, it has been in the development for over 4 years now.
It's based on Java and QT, and has an innovative interface by using tabs instead of extra windows.
Go ahead and install it and let me know what you think if you could.
I'd really like to get some people noticing that this exists, because it really deserves more attention than it's getting.
http://aur.archlinux.org/packages.php?ID=24962
1. Java? -> There is nothing slower, bulkier, buggier, and less responsive than Java. Thank you -> but no.
2. Why do we need another mplayer frontend?
3. What better things does it have to offer than the already excellent smplayer?

1. ...just try it and see...

2. Aura is a lot more than just an mplayer frontend. In fact I would like it to have other backends than mplayer.

3. Aura's interface is very much different and the UI is more responsive. I often load thousands of songs onto a playlist recursively based on a root folder. This isn't possible in smplayer and the way smplayer gathers meta information (which is also really sparse) is really slow because they load an mplayer process for each file. Also Aura has two different views that provide a sleek way of seeing a track's meta information and album art.

linkmaster03 · 2009-09-15 20:04:23

For those that don't think the Qt interface will look good with all their other GTK apps, I suggest doing this. It will make Qt apps use GTK natively.

If you think about it, Qt is great for the authors' aim of cross compatibility, because Qt uses native widgets on Windows and Mac.

Last edited by linkmaster03 (2009-09-15 20:04:59)

tomXx · 2009-09-15 21:08:06

hi,

i just installed auramp and tried to start it through my terminal.

[tom@knecht ~]$ auramp
[AuraMP] Initialized Logging session.
[AuraMP] Console Logger started Tue Sep 15 22:54:15 CEST 2009
[AuraMP] [V] Tue Sep 15 22:54:15 CEST 2009: Aura root execution directory: /home/tom
[AuraMP] [D] Tue Sep 15 22:54:15 CEST 2009: Startup arguments:
[AuraMP] [D] Tue Sep 15 22:54:16 CEST 2009: Aura NetCom unable to establish daemon. Assuming secondary instance.
[AuraMP] [M] Tue Sep 15 22:54:16 CEST 2009: Aura is already running.  To run multiple instances, you may override this check with the -multi-instance flag.
Hi:null

and the only thing i get to see, ist the splash screen and nothing happens.....

i appreciate any hint to get auramp to work

thx

DeeCodeUh · 2009-09-15 21:33:00

tomXx wrote:

hi,

i just installed auramp and tried to start it through my terminal.

[tom@knecht ~]$ auramp
[AuraMP] Initialized Logging session.
[AuraMP] Console Logger started Tue Sep 15 22:54:15 CEST 2009
[AuraMP] [V] Tue Sep 15 22:54:15 CEST 2009: Aura root execution directory: /home/tom
[AuraMP] [D] Tue Sep 15 22:54:15 CEST 2009: Startup arguments:
[AuraMP] [D] Tue Sep 15 22:54:16 CEST 2009: Aura NetCom unable to establish daemon. Assuming secondary instance.
[AuraMP] [M] Tue Sep 15 22:54:16 CEST 2009: Aura is already running.  To run multiple instances, you may override this check with the -multi-instance flag.
Hi:null

and the only thing i get to see, ist the splash screen and nothing happens.....

i appreciate any hint to get auramp to work

thx

You should already have auramp running. Check for it in the system tray.
The only problem we notice is that it shouldn't be printing out "Hi:null" lol, We'll get right on that part.

sakrag · 2009-09-16 07:26:53

tomXx wrote:

hi,

i just installed auramp and tried to start it through my terminal.

[tom@knecht ~]$ auramp
[AuraMP] Initialized Logging session.
[AuraMP] Console Logger started Tue Sep 15 22:54:15 CEST 2009
[AuraMP] [V] Tue Sep 15 22:54:15 CEST 2009: Aura root execution directory: /home/tom
[AuraMP] [D] Tue Sep 15 22:54:15 CEST 2009: Startup arguments:
[AuraMP] [D] Tue Sep 15 22:54:16 CEST 2009: Aura NetCom unable to establish daemon. Assuming secondary instance.
[AuraMP] [M] Tue Sep 15 22:54:16 CEST 2009: Aura is already running.  To run multiple instances, you may override this check with the -multi-instance flag.
Hi:null

and the only thing i get to see, ist the splash screen and nothing happens.....

i appreciate any hint to get auramp to work

thx

It may also be other things. AuraMP will attempt to open a socket bound to the loopback address on a specific port. If it is able to do this, it concludes it is the only instance of mplayer running. If it fails it attempts to send a packet to the other instance forwarding any files from the startup arguments and then closes. In your case it seems unable to open a socket and unable to contact another instance of AuraMP seeming to be either the process has no permissions to use sockets, the socket was already in use by another application, your loopback interface is currently down, etc.

This networking was added quickly and not long ago to allow someone to just launch AuraMP with a file, and if there is already an instance of AuraMP running, it would play in the current instance so only one instance is loaded and you dont have to wait for the startup time of a second instance. It also can be used to control AuraMP (play, pause, etc) through a plasmoid or similar widget. There is a lot that can be revised with our implementation at the moment.

sakrag · 2009-09-16 07:57:59

1. Java? -> There is nothing slower, bulkier, buggier, and less responsive than Java. Thank you -> but no.
2. Why do we need another mplayer frontend?
3. What better things does it have to offer than the already excellent smplayer?

1: Please explain? Do you have benchmarks you can provide? Have you used Jambi applications before?

2 & 3: I have used many mplayer frontends as well as used mplayer from the CLI. I feel that most of the frontends only
provide a ui to some basic features of mplayer. The aim of AuraMP is to eventually expose many more of the advanced
features of mplayer rarely found in other media players as well as provide some capabilities that are non existant in mplayer.
For example, AuraMP uses a 3rd party library for analyzing the meta tags of audio files. We feel that MPlayer's support
for meta information is somewhat lacking, and it would be almost impossible to bulk gather meta information from
multiple files using mplayer (as smplayer attempts to do rather inefficiently). Another is the audio visualizations we plan
on providing through ProjectM as mplayer does not provide this (neither does smplayer) and eventually provide an entire suite
for organizing a multimedia collection that can interface with services like imdb, lyrc, etc (which smplayer does not provide).

AuraMP's UI is also a little different than some mplayer frontends which I find more intuitive. Having everything readily available
at a click of a tab I find a lot more convenient than floating playlist windows that take up more screen space. Also we are thinking of
having all the panels able to float and dock as well as stack in a tab so its customizable.

The bottom line for why another MPlayer frontend: Like most projects, it started out as just a small personal project to make
something we feel is better than whats available. AuraMP actually started out as just a small video
previewer embedded in another java application (with just play, pause, stop functionality). After working on that I believed I could
create a full front end to provide some of the features I was looking for and I thought it may be a good learning experience. I never
even thought when I started that I would still be working on it today and trying to develop it for others to use.

DeeCodeUh · 2009-09-17 00:20:05

That's chapter two of Sakrag's new book he's writing about Aura...

Arch Linux

#26 2009-09-14 00:30:11

Re: A new mplayer front end is hitting the scene: Aura Media Player

#27 2009-09-14 03:18:18

Re: A new mplayer front end is hitting the scene: Aura Media Player

#28 2009-09-14 03:40:37

Re: A new mplayer front end is hitting the scene: Aura Media Player

#29 2009-09-14 13:29:56

Re: A new mplayer front end is hitting the scene: Aura Media Player

#30 2009-09-14 13:34:45

Re: A new mplayer front end is hitting the scene: Aura Media Player

#31 2009-09-14 14:14:25

Re: A new mplayer front end is hitting the scene: Aura Media Player

#32 2009-09-14 14:20:14

Re: A new mplayer front end is hitting the scene: Aura Media Player

#33 2009-09-14 15:17:47

Re: A new mplayer front end is hitting the scene: Aura Media Player

#34 2009-09-14 20:30:56

Re: A new mplayer front end is hitting the scene: Aura Media Player

#35 2009-09-14 20:36:32

Re: A new mplayer front end is hitting the scene: Aura Media Player

#36 2009-09-14 21:08:16

Re: A new mplayer front end is hitting the scene: Aura Media Player

#37 2009-09-14 22:22:32

Re: A new mplayer front end is hitting the scene: Aura Media Player

#38 2009-09-14 22:40:00

Re: A new mplayer front end is hitting the scene: Aura Media Player

#39 2009-09-15 00:38:08

Re: A new mplayer front end is hitting the scene: Aura Media Player

#40 2009-09-15 08:18:32

Re: A new mplayer front end is hitting the scene: Aura Media Player

#41 2009-09-15 08:29:36

Re: A new mplayer front end is hitting the scene: Aura Media Player

#42 2009-09-15 13:55:27

Re: A new mplayer front end is hitting the scene: Aura Media Player

#43 2009-09-15 13:57:30

Re: A new mplayer front end is hitting the scene: Aura Media Player

#44 2009-09-15 14:16:18

Re: A new mplayer front end is hitting the scene: Aura Media Player

#45 2009-09-15 20:04:23

Re: A new mplayer front end is hitting the scene: Aura Media Player

#46 2009-09-15 21:08:06

Re: A new mplayer front end is hitting the scene: Aura Media Player

#47 2009-09-15 21:33:00

Re: A new mplayer front end is hitting the scene: Aura Media Player

#48 2009-09-16 07:26:53

Re: A new mplayer front end is hitting the scene: Aura Media Player

#49 2009-09-16 07:57:59

Re: A new mplayer front end is hitting the scene: Aura Media Player

#50 2009-09-17 00:20:05

Re: A new mplayer front end is hitting the scene: Aura Media Player

Board footer