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

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?

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.

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...

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:

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.

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.

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 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?

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!

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.

> 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.

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...

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...

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.

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.

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.

...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.

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.