Application of the Month: JuK

Wednesday, 12 May 2004  |  Fmous

As part of the April 2004 issue of the "Application of the month" series on KDE.de, Andreas C. Diekmann has interviewed Scott Wheeler, author of Juk, an audio jukebox for KDE. Despite the downtime of the Dutch KDE website they are now offering an English translation of the interview as well as the overview of this issue for your reading pleasure.

Comments:

Juk is nice but is limited by its backend :( - Tim - 2004-05-12

I wanted to switch to juk, but since it depends on artsd and artsd doesn't seem to honor the .alsarc file properly there was no way in using juk. Besides i don't see a point in this artsd stuff. What are the advantages of artsd compared to use libalsa directly? And don't tell me it is simultaneous playing of multiple sounds! Besides it is really a pain to have all these backends playing nicely together. Jack, artsd, (the gnome thingy which i forgot the name, etc.). So if somebody could enlighten me why artsd is there and how it can be configured to honour the default card or other alsarc stuff? Cheers Tim

Re: Juk is nice but is limited by its backend :( - Anonymous - 2004-05-12

JuK also has an optional GStreamer backend.

Re: Juk is nice but is limited by its backend :( - c - 2004-05-13

which crashes far too much. :-(. sorry.

Re: Juk is nice but is limited by its backend :( - Michael Donaghy - 2004-05-12

Because some of us are still using OSS, or some other way of playing sound. Myself, I use OSS because I can compile it into a 2.4 kernel (And I'm stuck on 2.4 because of my winmodem). Arts is used so juk etc. only needs one sound output method programming. Of course the downside is that for cross-wm apps like xmms it means an extra output method needs coding.

Re: Juk is nice but is limited by its backend :( - Scott Wheeler - 2004-05-12

aRts (and GStreamer -- which JuK also provides a backend for) handles decoding, none of the other sound daemons that you mention do.

Re: Juk is nice but is limited by its backend :( - Robert - 2004-05-12

"What are the advantages of artsd compared to use libalsa directly?" The answer is there in the title. Advanced _Linux_ Sound Architecture. You make things plug straight into alsa and you rule out all platforms other than linux. Goodbye freebsd, openbsd, netbsd, solaris, hpux, irix...

Re: Juk is nice but is limited by its backend :( - David Johnson - 2004-05-12

"What are the advantages of artsd compared to use libalsa directly?" One huge advantage is that it doesn't limit KDE to just ALSA-fied Linux systems. KDE is a cross platform desktop. It works on Linux, Solaris, HPUX, FreeBSD, NetBSD, IRIX, etc. Only one of those uses ALSA...

Re: Juk is nice but is limited by its backend :( - Tim - 2004-05-12

Ok, an abstraction layer, thats ok. But i think that this artsd settings dialog and probably backend needs some big improvements concerning alsa. I suppose a majority of users uses Linux as base for KDE, and a lot of people use alsa as sound driver. For example these settings work with xmms and alsaplayer but not with artsd: pcm.!default { type plug slave.pcm "ch40dup" } pcm.ch40dup { type route slave.pcm surround40 slave.channels 4 ttable.0.0 1 ttable.1.1 1 ttable.0.2 1 ttable.1.3 1 } When i enable artsd i get the following error mesg: Unable to set interleaved. It is also not clear how to select output devices defined in the .asoundrc. I tried the -D flag from alsaplayer in "Weitere Benutzereinstellungen" or under "Eigene Hardwaredatei verwenden" the name. Nothing worked :(. Some really great wishlist item for me would be a party mode juk with a play queue of the next songs. Tim

Re: Juk is nice but is limited by its backend :( - Jason - 2004-05-13

What's wrong with a playlist?

Re: Juk is nice but is limited by its backend :( - Mr. Fancypants - 2004-05-13

Take a look at yammi (http://yammi.sf.net) for the difference between a play list and a play queue. I can tell you from personal experience that a play queue beats anything else (well, apart from a real DJ :)) for parties.

Re: Juk is nice but is limited by its backend :( - tpr - 2004-05-13

Well, it just doesn't do the same thing, and thus I tried to implement it some time ago. Anyways I found some problems I couldn't solve with my programming skills so I decided to leave it behind.. And yes, here is the URL for wish on bko: http://bugs.kde.org/show_bug.cgi?id=63260 - please vote for it if you like :)

I'd change to JuK - John JuK Wannabe Freak - 2004-05-12

I'm using SuSE 8.2 and I'd love to change to JuK now that I upgraded to KDE 3.2, still sound skips with every KDE media program (I assume it is a aRts issue)... anyone knows a workaround?

Re: I'd change to JuK - buddel - 2004-05-12

3.2.0 had many bugs. Most of multimedia applications hang. My own workaround was KDE 3.2.1.

Re: I'd change to JuK - John JuK Wannabe Freak - 2004-05-12

Thanks but I have 3.2.2 :-/

Re: I'd change to JuK - Geoff Rivell - 2004-05-12

I think it is to do with the buffering. On my wireless network, I have an SMB mount and the mp3's skip with JuK. On XMMS I just set a higher buffer (and not have it use aRts. I suspend aRts for XMMS because it seems aRts is the reason for skipping?

Re: I'd change to JuK - John JuK Wannabe Freak - 2004-05-12

Xmms works fine here, I do think it doesn't use aRts by default. Tried to change the size of the aRts buffer in KControl but it didn't help.

Re: I'd change to JuK - David - 2004-05-12

Same here, XMMS works fine, but everything related to aRts is a disaster... tried 2.6.x and that made a BIG difference but not stable enough for day to day work... But it's a shame that we have to use XMMS as I find juK to be much nicer! /David

Re: I'd change to JuK - Jake - 2004-05-13

I use kde 3.2.2 and mdk-kernel 2.6.3-8. It works fine most of the time, but skips when the harddrive is used heavily or I crunch the CPU. I used to use mdk-kernel 2.6.3-3 and updating really helped. Still, artsd is a piece of crap, IMO, and one of kde's weakest points. Do your bit to let the developers know how poor artsd is! vote for http://bugs.kde.org/show_bug.cgi?id=61737 and http://bugs.kde.org/show_bug.cgi?id=74744 (it only takes a few moments to register!)

Re: I'd change to JuK - Henry - 2004-05-13

It seems the general consensous of KDE develors is that artsd sucks--maybe not as an API, but for end-users. I have no problem with having an abstraction layer, but artsd is very weak in lots of respects. I pretty much don't use KDE for sound at all *because* of artsd. I was using Noatun about a year ago, but I've switched to XMMS. For compatibilities sake, would it be possible to use GStreamer as the abstraction layer? I guess the API probably wouldn't be very friendly to us C++ folks.

Re: I'd change to JuK - coulamac - 2004-05-13

Just wrap the GStreamer C api into KDE-style C++ apis. (I believe this has already been done, too.) Then you have "developer friendly" to C++ folks. Cheers!

Re: I'd change to JuK - anonymous - 2004-05-13

And then you have a wrapper library that has to be changed/fixed everytime the API changes underneath (Gtk-- anyone). Yeah!

Re: I'd change to JuK - Henry - 2004-05-13

I forgot to mention, those KDE bug reports don't seem related. They seem to deal with artsd CPU utilization. And we know off-topic bug comments aren't taken seriously.

Re: I'd change to JuK - Rom1 - 2004-05-13

Try the new 2.6.6 with the CFQ scheduler (append "elevator=cfq" to the kernel's boot parameters). Without it arts was useless for me as soon as the hard drive kicked in. Now it's working fine. CFQ is also in the -mm tree for the "2.6.x, x<6" series. HTH R.

Re: I'd change to JuK - Scott Wheeler - 2004-05-13

> Still, artsd is a piece of crap, IMO, and one of kde's weakest points. Well, on the topic of JuK -- it's been noted in this thread and elsewhere that JuK has provided a GStreamer backend since its first release. To be honest, almost everyone is too lazy to do it since it's a lot easier to just complain about aRts. ;-) > Do your bit to let the developers know how poor artsd is! "The developers" are familiar with the problems with aRts (and randomly spamming bug reports won't help). But we're stuck with it until at least KDE 4. At that point we'll almost certainly be switching to something else, though there is still some debate on what exactly. See the kde-multimedia development list archives for more.

Re: I'd change to JuK - mETz - 2004-05-13

turning on realtime-priority for artsd and making sure that the artwrapper binary is setuid root does wonders.

Re: I'd change to JuK - John JuK Wannabe Freak - 2004-05-14

Yeap, did all that and all was fine... but thank you all for your help and sorry about the (OT?) question.

not enough codecs supported - Lilly - 2004-05-13

I love Juk and use it as much as possible. Sadly, the backend, artsd is the weakest link. It skips and doesn't support .mpc, .ape or .wma despite plugins for all of these being available for xmms and mplayer. These are popular formats nowadays and I hate having to use a konqueror/xmms combo to play a lot of my music...

Re: not enough codecs supported - superstoned - 2004-05-13

thats my main problem with arts too... alot of my music is in musepack format, and I cant play it. and arts crashes alot, too - while it doesnt skip as much as xmms does for me. And I love Juk's interface. Nice it supports Gstreamer, but Gstreamer can't play mpc either...

Re: not enough codecs supported - mETz - 2004-05-13

Probably because nobody knows about mpc :) wma could be played through xine_artsplugin but that probably needs a little tweak (the wma mimetype needs to be linked to that plugin).

Re: not enough codecs supported - Stephen Douglas - 2004-05-13

TagLib would have to be extended to support reading tags from .wma as well. I think Scott's previously said that's not going to happen.

Re: not enough codecs supported - c - 2004-05-13

aye. lack of mpc support is the biggest kick in the teeth for me too. I love juk (especially the tag editting stuff) but xmms is just way more flexible. throw in the artsd mess (3.2.2 keeps crashing arts) and buggy gstreamer plugin and it's amazing I use Juk at all. says a lot about how good the tag editor is.

Re: not enough codecs supported - Scott Wheeler - 2004-05-13

mpc was just very recently made OSS. They haven't even done a release based on the OSS version yet and the version available from their source repository doesn't actually build on Linux. I'll consider adding support for it once this stuff comes around.

Re: not enough codecs supported - superstoned - 2004-05-13

their decoder (which is, I guess, actually needed for playback) has been OSS since the beginning, afaik... anyway, thanks for the work!

Re: not enough codecs supported - Scott Wheeler - 2004-05-13

I have a policy in JuK / TagLib of not implementing formats for which a F/OSS encoder does not exist (as I'm not particularly interested in encouraging the use of proprietary formats in an area where more open formats are dominant.). Until quite recently the encoder was available in binary format only.

Re: not enough codecs supported - Lilly - 2004-05-14

There is an mplayer and an xmms plugin available for .mpc files. What about .ape? It's an increasinlgy popular lossless codec. There license is a bit weird (you have to ask permission) but after that your good to go. There is active linux development and I believe that an xmms plugin exists.

Re: not enough codecs supported - Scott Wheeler - 2004-05-14

...except that having to ask for permission is GPL incompatible. Please see the above comment. I don't see any reason to encourage the use of proprietary codecs when they're less popular than open formats. FLAC is already more popular than APE and I don't know of any significant benefits that APE offers that would convince one to use it over something less restrictive. And in the case of lossless codecs, transcoding is an easy options since, well, it's lossless.

Re: not enough codecs supported - axion - 2004-09-13

yep, lack of mpc support is the reason i still use xmms as well.

Needs Plugin Support. - Meldroc - 2004-05-13

There's one reason why I'm still using XMMS instead of Juk. XMMS has some awesome plugins - everything from visualizations to alarm clocks, as well as input and output plugins so you can input zillions of different file formats, and you can output to ALSA, ARTS, OSS, to a file, etc. Mostly, I use the IMMS plugin (http://www.luminal.org/wiki/index.php/IMMS/IMMS) to automagically rate my music, play good music more often, etc. So far, there is no plugin interface for JuK. It needs one.