"Uzbl-like" music player out there?

Themaister · 2009-10-20 21:22:00

I've been trying Uzbl lately, and it hit me, the concept of breaking down a traditionally monolithic application like a browser, into a Unix-like modular approach is really nice.

Now, I wonder if there is a project like this, just for music out there?
You have the CLI music players like moc and mpd, but they still don't let you fiddle with the design of the application as far as I know, unless you're a good C programmer with lots of spare time, of course.

Let's say you start off with a really bare-bone module which pretty much only plays raw PCM while it lets you build around it with scripts, plugins, etc to implement the functionality you need. It might be a long shot, but it could be a good idea I think if it's done right from the start. Of course directed towards the minimalist *nix user. Adding support for sound formats will be a really simple task as long as there is a decoder app available (ffmpeg perhaps?), and also adding support for different drivers (ALSA, OSS, etc), as only the PCM playing module needs to be changed.

Anyone thinks it's a good idea?

Last edited by Themaister (2009-10-20 21:22:52)

sand_man · 2009-10-20 22:34:24

Sounds like a good idea if anyone wanted to take it up.
Personally I don't use Uzbl and I probably wouldn't use this either (if it existed) but the concept is geeky which I like.

anrxc · 2009-10-20 23:03:27

cplay is a good project. It is a front-end to various audio players/decoders written in Python and so very easy to hack. I spent a lot of time patching it, code is easy to understand. Others did the same, adding stuff like an EQ.

Project wasn't updated in a long time it would be nice if someone used it for something, improved it, split into modules or whatever. It's a good project, it shouldn't be forgotten.

skottish · 2009-10-21 00:15:06

The copy of MPD on my system is built against no codecs outside of FFmpeg and it seems to play anything that I throw at it. My system does not have libvorbis or faad2 installed. I haven't tested anything flac lately, but aac, alac, wav, and vorbis, all work. So if you wanted to start with FFmpeg as your base...

--EDIT--

flac works too. I'm impressed by mpd getting cooler all the time.

Themaister · 2009-10-21 05:53:37

anrxc wrote:

cplay is a good project. It is a front-end to various audio players/decoders written in Python and so very easy to hack. I spent a lot of time patching it, code is easy to understand. Others did the same, adding stuff like an EQ.
Project wasn't updated in a long time it would be nice if someone used it for something, improved it, split into modules or whatever. It's a good project, it shouldn't be forgotten.

Sound nice, I'll check it out.

Dieter@be · 2009-10-21 12:01:52

I am also looking for something like this.
I think however that cli-only is a very good goal for a music player. (unlike uzbl which has to render graphical things with images and such)
probably something that has no interface at all (other then a unix socket) would be ideal to control the application. with tools and scripts like dmenu/zenity/.. you can do what you want.

Mpd gets pretty close to what I'm looking for, but my biggest gripe with it is that it's meant as a system-wide daemon, so you need root to do certain things. (actually I should do more testing to see if I can do everything as normal user). also mpd has the concept of its music database, playlists, etc. I think these concepts belong outside of the player.. (like with uzbl where you have your history and bookmarks in separate files, and it's up to your scripts to retrieve a certain item and have uzbl load it)

Moc is also pretty cool: very lightweight and simple, but no scripting/integration support

I heard cplay was unmaintained, so I haven't tried it yet.

Last edited by Dieter@be (2009-10-21 12:04:41)

Themaister · 2009-10-21 14:33:29

I wonder if you can even avoid using sockets, and just pipe PCM to the app, and to control the app itself (seeking, etc, which is kinda useful I think, etc) you simply raise signals that makes the program behave in desired ways, etc, from a script, etc? :3

Dieter@be · 2009-10-21 14:55:16

Themaister wrote:

I wonder if you can even avoid using sockets, and just pipe PCM to the app, and to control the app itself (seeking, etc, which is kinda useful I think, etc) you simply raise signals that makes the program behave in desired ways, etc, from a script, etc? :3

so how would you tell the app "play file /path/to/filename" ?
what do you mean with 'pipe PCM' ? are you talking about audio data? the only application that should be concerned with actual audio data is the "core" uzbl-ish audio application we're looking for

xd-0 · 2009-10-21 15:09:33

Lately I've been using pymp as a music player. Even though it's not uzbl-ish it's very slim, and could need some love.

edit: posted it here because the people that is looking at this thread also might be the ones who could like it.

Last edited by xd-0 (2009-10-21 15:10:55)

Nezmer · 2009-10-21 16:52:39

Alternatives and new ideas are always good .

The thing is , MPD was around enough to be supported by many custom apps and plugins(conky and wicked for example) . That gives you easy integration .

The only feature I wish I had available in MPD is a way to amplify the volume . I suggested doing this with soft mixing (like softvol-max in mplayer) but a developer refused the idea instantly .

Dieter@be · 2009-10-21 17:02:15

xd-0 wrote:

Lately I've been using pymp as a music player. Even though it's not uzbl-ish it's very slim, and could need some love.
edit: posted it here because the people that is looking at this thread also might be the ones who could like it.

holy shit !
i fetched the sourcecode of pymp.. this program is 1700 lines of (on first sight) well written and nicely commented python code. and thanks to it's simple mplayer.py file i learned about mplayer's slave mode where it reads commands from stdin.

this is looking good.. mplayer in slave mode + socat to have a socket (so you can automatically start mplayer through .xinitrc or whatever and use the socket file) seems - on the first sight - like a great uzbl-alike media player. that, in combination with other tools and scripts (for which you could borrow code from pymp)...
definiteley something to look into.
it's a bit ugly because you have to parse stdout for your responses though. and i wonder how the commands such as `get_percent_pos` and `get_time_pos` work. they are not mentioned in mplayers manpage

edit: oh look, it can read commands from fifo's see '-input'

Last edited by Dieter@be (2009-10-21 17:05:27)

Themaister · 2009-10-21 20:43:19

Dieter@be wrote:

Themaister wrote:
I wonder if you can even avoid using sockets, and just pipe PCM to the app, and to control the app itself (seeking, etc, which is kinda useful I think, etc) you simply raise signals that makes the program behave in desired ways, etc, from a script, etc? :3
so how would you tell the app "play file /path/to/filename" ?
what do you mean with 'pipe PCM' ? are you talking about audio data? the only application that should be concerned with actual audio data is the "core" uzbl-ish audio application we're looking for

Something like:

flac -d -c "$file" | theplayer (could probably just have been alsaplayer as it is now, lol It's about 30-40 lines of C so far, using alsalib ... )
# insert lots of other decoders here for different file types in a huge "case/esac".

I guess. I already have a really simple playlist manager/player setup which works that way using simple bash-scripts. The big issue with it is that implementing seeking is generally a really bad hack using this naive approach. But, of course, an uzbl-like player's core need to be a bit more sophisticated than that.

An MPlayer in slave mode from pymp looked kinda nice though.

Last edited by Themaister (2009-10-21 20:44:11)

Rasi · 2009-10-21 21:49:54

Nezmer wrote:

Alternatives and new ideas are always good .
The thing is , MPD was around enough to be supported by many custom apps and plugins(conky and wicked for example) . That gives you easy integration .
The only feature I wish I had available in MPD is a way to amplify the volume . I suggested doing this with soft mixing (like softvol-max in mplayer) but a developer refused the idea instantly .

you DO know mpd supports replaygain? use the preamp setting to pre-amplifiy your (replaygained) files to your liking...

skottish · 2009-10-22 05:31:52

One thing that everyone is going to have to watch for here is gap-less playback. You're simply not going to get it without buffers through apps like Mplayer and FFplay. Even Xine's version is a total hack. This is going to be just as problematic with piping things. At some point there's going to need to be a buffer large enough to start caching the next song and fast enough for things to seem real time.

Dieter@be · 2009-10-22 09:44:22

skottish wrote:

One thing that everyone is going to have to watch for here is gap-less playback. You're simply not going to get it without buffers through apps like Mplayer and FFplay. Even Xine's version is a total hack. This is going to be just as problematic with piping things. At some point there's going to need to be a buffer large enough to start caching the next song and fast enough for things to seem real time.

mm you have a point here. i have to check it out but i guess/hope mplayer has an option to specify some files on the beforehand to play next.
but mplayer has no socket.. i looked at vlc and it seems to support a lot more interfaces, such as telnet(tcp)/unix socket/...

skottish · 2009-10-23 00:57:59

grep through the ffmpeg source code and see if any of it's sockets are usable. If so, connecting to ffserver may be an option.

Dieter@be · 2009-10-23 20:09:18

Dieter@be wrote:

skottish wrote:
One thing that everyone is going to have to watch for here is gap-less playback. You're simply not going to get it without buffers through apps like Mplayer and FFplay. Even Xine's version is a total hack. This is going to be just as problematic with piping things. At some point there's going to need to be a buffer large enough to start caching the next song and fast enough for things to seem real time.
mm you have a point here. i have to check it out but i guess/hope mplayer has an option to specify some files on the beforehand to play next.
but mplayer has no socket.. i looked at vlc and it seems to support a lot more interfaces, such as telnet(tcp)/unix socket/...

loadfile <file|url> <append>
Load the given file/URL, stopping playback of the current file/URL.
If <append> is nonzero playback continues and the file/URL is
appended to the current playlist instead.
loadlist <file> <append>
Load the given playlist file, stopping playback of the current file.
If <append> is nonzero playback continues and the playlist file is
appended to the current playlist instead.

http://www.mplayerhq.hu/DOCS/tech/slave.txt

edit: hmm bct just told me the playlist support in mplayer is poor (no way to get a list of items in playlist, delete items, etc)

the good news is, vlc supports that, and all its responses come over the unix socket so no need to parse stdout.

for those who want to play, this will get you started:

vlc -I rc --rc-unix $socketname
echo h | socat - unix-connect:$socketname #for a list of commands
mkfifo $fifo
mplayer -idle -slave -input file=$fifo

Last edited by Dieter@be (2009-10-23 20:39:28)

Dieter@be · 2009-11-01 08:39:26

Okay, who will write the new killer vlc-based uzbl-like media player?
I've been playing a bit with vlc's socket feature and it's nice. it just needs some bash/python/... scripts for playlist management and such.
I don't have the time for yet another project.

aev- · 2009-11-01 09:17:28

I've been thinking about this recently. The most important thing for me would be using the filesystem as database and for playlists or to be more precise: use something like FUSE to sensibly sort my music (the idea isn't new though: https://gna.org/projects/tagsfs , dunno if that one is any good). Also I like the mpd daemon idea (but perhaps running the player inside screen is just as good).

Since the consensus seems to be vlc: why not make it as player agnostic as possible (ie provide a script that can communicate with the more popular and common players)?

Dieter@be · 2009-11-01 09:35:27

aev- wrote:

Since the consensus seems to be vlc: why not make it as player agnostic as possible (ie provide a script that can communicate with the more popular and common players)?

consensus? I compared it to mplayer and I prefer it over mplayer (because it supports a unix socket and has a better command interface). But I didn't see anyone else saying an explicit preference.

And since the player that will be built is essentially just a wrapper of which all code is meant to interface with the "backend player", making it "player agnostic" would basically mean rewriting the entire program for all players out there. I suggest to pick one good backend and work on that. Why would you even need to support multiple backends if you only need one good one.

aev- wrote:

Also I like the mpd daemon idea (but perhaps running the player inside screen is just as good).

are you confusing the backend player with the interface? you could/should run the backend in the background (daemonized). (e.g. I put "vlc -I rc --rc-unix $socketname &" in my .xinitrc)
then you can connect to it with any UI/command interface/script and disconnect from it

aev- · 2009-11-01 10:13:01

Dieter@be wrote:

consensus? I compared it to mplayer and I prefer it over mplayer (because it supports a unix socket and has a better command interface). But I didn't see anyone else saying an explicit preference.

You made the suggestion and from my understanding no one made specific endeavors to actually write this thing.

Why would you even need to support multiple backends if you only need one good one.

Well, true, but then why not just use vlc's ncurses interface? It would perhaps conflict the idea of how to control it but if that is the aim, mpd+mpc is perfect already.

EDIT: I don't even disagree with you but using vlc with some scripts sounds a lot worse than other available programs.

are you confusing the backend player with the interface?

Yes, my bad.

Last edited by aev- (2009-11-01 10:15:22)

Dieter@be · 2009-11-01 10:26:20

aev- wrote:

Why would you even need to support multiple backends if you only need one good one.
Well, true, but then why not just use vlc's ncurses interface? It would perhaps conflict the idea of how to control it

A good way to control it is what this is all about.

aev- wrote:

it but if that is the aim, mpd+mpc is perfect already.

nope. I will quote myself:

Dieter@be wrote:

Mpd gets pretty close to what I'm looking for, but my biggest gripe with it is that it's meant as a system-wide daemon, so you need root to do certain things. (actually I should do more testing to see if I can do everything as normal user). also mpd has the concept of its music database, playlists, etc. I think these concepts belong outside of the player.. (like with uzbl where you have your history and bookmarks in separate files, and it's up to your scripts to retrieve a certain item and have uzbl load it)

Last edited by Dieter@be (2009-11-01 10:26:40)

aev- · 2009-11-01 10:40:36

Ok (btw: http://wiki.archlinux.org/index.php/MPD … ive_Setup)

Dieter@be · 2009-11-01 10:57:28

aev- wrote:

Ok (btw: http://wiki.archlinux.org/index.php/MPD … ive_Setup)

great. that changes things a lot.
I'll give mpd another chance. Given the fact that it's a well established player with a decent community, I guess I'm okay with it that it does playlists/media library internally.
In fact I just noticed the database file is just a plaintext file.

skottish · 2009-11-01 15:40:34

There's great improvements with MPD now. As mentioned before, It will create a new database automatically now and update it through inotify. Although, this won't work with the old database so that one needs to be moved/removed. Also mentioned before, it can use a pure FFmpeg back-end if configured properly. That one needs a patch based on a bug report that I filed to work properly if MPD isn't built against other libraries:

http://lists.mplayerhq.hu/pipermail/ffm … 77785.html

Arch Linux

#1 2009-10-20 21:22:00

"Uzbl-like" music player out there?

#2 2009-10-20 22:34:24

Re: "Uzbl-like" music player out there?

#3 2009-10-20 23:03:27

Re: "Uzbl-like" music player out there?

#4 2009-10-21 00:15:06

Re: "Uzbl-like" music player out there?

#5 2009-10-21 05:53:37

Re: "Uzbl-like" music player out there?

#6 2009-10-21 12:01:52

Re: "Uzbl-like" music player out there?

#7 2009-10-21 14:33:29

Re: "Uzbl-like" music player out there?

#8 2009-10-21 14:55:16

Re: "Uzbl-like" music player out there?

#9 2009-10-21 15:09:33

Re: "Uzbl-like" music player out there?

#10 2009-10-21 16:52:39

Re: "Uzbl-like" music player out there?

#11 2009-10-21 17:02:15

Re: "Uzbl-like" music player out there?

#12 2009-10-21 20:43:19

Re: "Uzbl-like" music player out there?

#13 2009-10-21 21:49:54

Re: "Uzbl-like" music player out there?

#14 2009-10-22 05:31:52

Re: "Uzbl-like" music player out there?

#15 2009-10-22 09:44:22

Re: "Uzbl-like" music player out there?

#16 2009-10-23 00:57:59

Re: "Uzbl-like" music player out there?

#17 2009-10-23 20:09:18

Re: "Uzbl-like" music player out there?

#18 2009-11-01 08:39:26

Re: "Uzbl-like" music player out there?

#19 2009-11-01 09:17:28

Re: "Uzbl-like" music player out there?

#20 2009-11-01 09:35:27

Re: "Uzbl-like" music player out there?

#21 2009-11-01 10:13:01

Re: "Uzbl-like" music player out there?

#22 2009-11-01 10:26:20

Re: "Uzbl-like" music player out there?

#23 2009-11-01 10:40:36

Re: "Uzbl-like" music player out there?

#24 2009-11-01 10:57:28

Re: "Uzbl-like" music player out there?

#25 2009-11-01 15:40:34

Re: "Uzbl-like" music player out there?

Board footer