Open for Business associate editor Eduardo Sánchez interviewed Scott Wheeler, creator and lead developer of JuK and a member of the KDE Multimedia team to find out where the KDE multimedia department is headed in general, and concerning a replacement for aRts, more specifically.
Dot Categories:
Comments
I haven't tried it myself, but wouldn't that be close enough to the goals of aRTs? Any ideas?
jack is only for routing (plugging) audio and midi streams, it will provide a simple way to play an audio file.
i think jack can easily be used underneath, or on top of gstreamer/NMS/MAS. Allthough gstreamer/NMS/MAS provide functionality that is similar to jack (at least for audio).
I dont know how any of these systems compares to arts. I dont know nor understand arts, i just seem to use it...
_cies.
Jack is the standard for professional audio applications on Linux. It is the right choice for 24 bit audio, high sample rate, good routing and serious real time. Jack makes Linux a viable platform for musicians. For example Jack allows to combine au audio sequencer for virtual synthesizers and reverb. components.
JPS.
One thing I can't seem to get my brain around are since neither Gstreamer or NMM are soundservers, what are going to be used as soundserver if KDE goes for one of them. A soundserver are still needed right? Are you planning too go for a cut down soundserver only version of aRts, Esd , Jack or something else? I can't remember to have seen this questions addressed anywhere. Whats the plan, curious and slightly comfused.
With the advent of modern audio frameworks like Alsa, sound servers are not really needed any longer for the majority of users. The main purpose of sound servers is the mixing of multiple audio streams, which can either be done in hardware, e.g. with a soundcard like SBlive, or in software, e.g. with Alsa's "dmix" plugin.
To my knowledge there are still some platforms that do not support native mixing (e.g. Solaris), but most modern platforms (Linux, FreeBSD) provide such a facility, which is much more elegant than a clunky soundserver. Those users that still need a soundserver could still select it, of course, since multimedia frameworks like GStreamer allow to select different output plugins. But there's no need to install a sound server by default on every box.
What really needs to be done is a device-driver level client/server... I have my workstation setup to use ASLA... I have an xterminal I use to log occasionally... In order to get sound on the xterminal, I have to reconfigure my various apps to use aRts/esd/whatever.. And every app is different.. Some support ESD, some Arts, etc.. So to get my apps to work, I have to have ESD and arts running.. What a waste!
ALSA is very good at emulating OSS, so all my apps work with it.. if we can get a "remote PCM" device driver, alot of my issues would disappear..
That being said, I think there was some work towards that.. I looked a week or so ago, and found some thread about aserver or somesuch.. I looked briefly at code, and it looks like the beginings of it..
--Garion
Is it theoretically possible that, with the correct kernel modifications, we could one day access device files on remote computers via for example NFS - that is, set your app, running on a server, to use /mnt/myterminal/dev/dsp (or even symlink the server's /dev/dsp to it) and get sound on the "myterminal" machine...?
No.
A device file (like /dev/dsp) is nothing more than two numbers.
[ralsina@roberto edubook]$ ls -l /dev/dsp
crw------- 1 ralsina root 14, 3 feb 23 2004 /dev/dsp
14 and 3 in this case. Those numbers are the same for every device file on every box. Accessing a device file over nfs still accesses your own soundcard (try it).
Thanks for the answer. I wonder if this could be considered a Unix design flaw (I've more than once wanted to access devices in this way, serial ports connected to different pieces of homemade hardware on remote machines, for example). Then again, the whole Unix device file model is often criticized for being a bit ad-hoc...
It's not that it can't be done. It's just that it can't be done that way.
For example, if you want to do this for serial ports, you use remserial
http://lpccomp.bc.ca/remserial/
Of course there's no such thing as a pty for sound devices, but one can only hope ;-)
The question was something *like* NFS, so the answer should be "yes, if the file system in question was extended to handle device nodes". Linux has the NBD which handles block devices. Writing a networked file system that could handle char devices should be trivial. But, no, I don't know of any existing ones. People generally use sound servers instead.
On NFS you access a NFS filesystem, which contains files. When you open the files, NFS maps the actions to the remote server.
Using NBD, you have a device, which is a NBD device. Not a filesystem.
It's not at all like NFS, since it makes no attempt to look like a filesystem.
If you access the NBD device over NFS, it is again your local NBD device. That's because when the kernel is told "read from this device file" he doesn't care at all on what filesystem such file is. It's the wrong layer of abstraction.
Isn't this what NAS - "Network Audio System" is for?
Sorry, but:
a) You are posting in a months-old thread.
b) You are very confused.
what about api? is there a KDE api for gstreamer or is juk and amarok using the ugly c api?
Yeah we use the ugly C API.
Hmmm, then I think that is a big minus for gstreamer.
Well, there are bindings for KDE, you're free to use them.
The KDE bindings are stuck at Gstreamer 0.6, so both amarok and juk use the native c-interface.
In short, gstreamer KDE is not well-maintained. NMM is looking better and better.
I've tried GStreamer with both Amarok and Juk, and apart from some quirks with a few mp3 files for no apparent reason and some timing issues it works OK.
I've also tried them with NMM, and I have to say NMM is one cool bit of software. It's a bit of work to compile and the nice NMM guys provide binaries, but it works pretty well, sounds good and the latency is pretty good. For some reason, it was far worse with GStreamer whilst doing other things but I haven't been able to quantify it. It probably isn't GStreamer but some of the ways in which interfacing is done between Juk/amarok/GSteeamer.
However, the cool things you can do with NMM over a network is also pretty mind-blowing, and it all works pretty great.
Seriously though, if the bindings cannot catch up with the GStreamer current version in a reasonable amount of time so that you're ending up using a C API then there really isn't a whole lot of point in bindings or putting effort into maintaining them. I've never bought the "Oh, you can make bindings for it" argument with GStreamer unfortunately. NMM as a default and native C++ base is looking by far the better option.
I know people desperately want KDE to use GStreamer by default because of the sake of some touchy-feely Gnome compatibility thing, but it just doesn't work like that. If it isn't maintainable to have clean bindings and interfaces with GStreamer now, then imagine what it's going to be like when GStreamer could be used by default and heavy development is going on for a KDE release..... Did people say that something better than arts is required?!
I second your view, in each and every point you made. I admit that I did not tried yet NMM (nor gstreamer) by myself, but technically NMM really looks like a better alternative:
- No binding needed,
- C++, so it should integrates with kde's internationalisation easily,
- Network tranparency
- Clean API (from what i saw in doxygen docs)
Anyway, from what I saw in the article, kdemultimedia team is considering developping a middle layer between KDE and any sound back-end. This is a good idea too. Once that done it would be possible to swicth from Gstreamer to NMM or anything else.
I think so, too. Unfortunately the NMM guys provide one fat tarball, instead maybe core, plugins, qt-tools and some of the plugins are not up to date, to say the least. One can't say, they make it easy for interested people.
To be fair, it is made up of plugins - they just provide most of them in one installation package.
>they just provide most of them in one installation package.
I did not say anything else.
"Unfortunately the NMM guys provide one fat tarball, instead maybe core, plugins, qt-tools and some of the plugins are not up to date"
In providing an easy to install tarball not every component is necessarily going to be up to date. You can't get any easier than that really, and installing GStreamer and all the right plugins is certainly not easy.
You complained about there being one tarball to download, then you complained that things are not up to date etc. You didn't grasp that you can't have everything.
>You complained about there being one tarball to download, then you complained that things are not up to date
Right, this are two issues, I had with the software, when trying it, both more or less independent from each other. I had the idea to provide ebuilds, but not as a single one with a thousand use flags and dependencies. This would mean that I'd need to re-tar it in smaller pieces or let the whole tarball be unpacked for every single ebuild. Also I'm (and the users are) not interested to downgrade a whole bunch of media libs and recompile other applications, which depend on them, just to test NMM. The latter point is the reason, why I dropped the idea.
I think it is very reasonable of the NMM maintainers to include as many dependecies as possible to make quick testing easy, for example allowing to install into a user writeable prefix, etc.
When you are creating packages for installation under control of a packagemanager, you have to decide if you want to make your life easy, i.e. create one package per upstream tar ball, or create a couple of packages to fit into the rest of the package repository and therefor making the life of the other users easy.
Of course distributions with traditionally fine grained packages are more work to package for, but the high flexibility of what to install is what makes them so popular among their users.
This is something of a chicken-and-egg problem though. When I looked at updating the bindings I realized that it'd be a couple weeks of work. Not too bad, but not a weekend project. They'd need to be several thousand lines of code. And there'd be exactly one application using them, where the native GStreamer code is all of about 150 lines of code. And they wouldn't be packaged anyway.
In terms of time it simply wasn't worth the investment for me since I have about 8 times as many projects as I have time for as is.
Now things there change for the KDE 4 picture. If we're seriously looking at having bindings that are used by more than JuK, then it becomes worth the time to create them. It's not particularly hard, just a bit tedious.
Are anyone actually using Noatun? I accidentally encounter it whenever I reinstall and e.g. need to test sound/video, but always seem to be able to crash it (Mostly when playing with the skins and plugins, though). I have too many media files in proprietary formats it does not seem to handle, the whole GUI turns unresponsive as it goes through the playlists to reject the different media files. And three keyboard buttons to go to fullscreen, but not the same buttons to exit fullscreen? Okay, turning into incoherent rant, but Kaboodle and Noatun really are two annoying programs. Amarok is great for music, and hopefully I'll settle down for Kaffeine or Kmplayer soon for video. The fast forward/backward in movies with the scroll wheel you have in gmplayer is superior to anything else, though. IMHO, etc.
Actually I use noatun all the time. I am currently using the one from kde 3.3.1 in debian sid and the last time it crashed was several years ago. About 90% of my music are oggs that I encoded and the rest are mp3s that I encoded long ago. I just have not had the issues with noatun that others have had. However I have used amarok and just did not like it.
In amarok I found no way to just click on a song once and have it play but I can do that with the noatun default playlist. Amarok also did so many things that I had to spend time trying to figure out how to disable since I just want a playlist for music that I can jump around in. I don't want music catagorized, etc. In the noatun default playlist it is easier for me to just load up a directory to play (all my music is already catagorized) and have it start playing. I don't know about the various guis for noatun since I don't really use any of them. When noatun starts you can click on the little icon for it in your system tray and it will minimize to that icon. You can then use the keyz plugin for it to control it from the keyboard so you don't have to bother with it and you can also click on the playlist to quickly jump around.
I don't do much in the way of videos. I have watched various trailers in kaboodle with no issues though so it works well enough for what I have used it for.
I used to use Noatun with Hayes. Now I use AmaroK and am very happy with it.
> since I just want a playlist for music that I can jump around in.
AmaroK -> "Settings" -> "Configure AmaroK" -> "General" -> uncheck "Show Player Window"
> In the noatun default playlist it is easier for me to just load up a directory to play (all my music is already catagorized) and have it start playing.
Depending on how big you music collection is. Loading of large directories can be insanely slow in Noatun.
> When noatun starts you can click on the little icon for it in your system tray and it will minimize to that icon.
Same with AmaroK.
> You can then use the keyz plugin for it to control it from the keyboard so you don't have to bother with it and you can also click on the playlist to quickly jump around.
AmaroK -> "Settings" -> "Configure Global Shortcut"
Charles
>> since I just want a playlist for music that I can jump around in.
> AmaroK -> "Settings" -> "Configure AmaroK" -> "General" -> uncheck "Show Player Window"
That will get rid of the player window but it still leaves the problem that you can't single click on an item in the playlist and have it start playing. Everything else in kde seems to be single click by default so why should that be double click? When I click on a folder in kmail, a message in kmail, a directory in konqueror, one of the songs in the noatun playlist all of those are single click by default.
>Depending on how big you music collection is. Loading of large directories can be insanely slow in Noatun.
I really have not experienced that. I will load up a directory structure which has 400 or so songs in it in < 4 seconds which seems easily fast enough. All my music is organized so when I want to play a different kind of music I load up that directory instead.
I know you can configure amarok to do some of these other things that noatun can do however it can't do some of the things that I really want, namely that you need to doubleclick it instead of singleclick and none of the rest of the features really matter to me that it has.
I have used the keybindings in amarok I have used the arts and gstreamer output plugins but overall the various features it has I just don't need very much. The playlist not being single click is the biggest issues for me and the other issue I have is getting the playlist to be as narrow as the default noatun one which I usually leave up all the time. Amarok is a nice media player but it does a lot of stuff that I don't need and it makes the most common way I play music a lot harder.
This is a screenshot of my desktop http://aesaeion.com/mydesk The large black areas are because the monitors are not all the same size.
How do you highlight files if clicking on them once starts playing it?
What do you need to hightlight the files for?
to move, copy etc them...
I have KDE set up for doubleclick, so I dont dislike this behaviour, but you are right - at least it should follow the settings in this.
and you load a directory (wait 4 secs) every time you want other music? try juk... just (double...)click a playlist (and you always see them on the left) and it plays. if you want a simple and usefull interface, try juk. amarok is a bit worse imho on usabillity (at least they should replace their playlist tab with juk's playlist system, eg drag'n'drop, a collection playlist etc. whould make it much easier).
>to move, copy etc them...
Well I don't move, copy etc from within the playlist however it is easy to move stuff you click once and hold the button down and drag the item where you want it in the playlist. The same thing works in konqueror, just click a file, group of files, directories etc and drag them where you want them and it asks if you want move, copy or link.
To get properties of stuff in konqueror just right click on the item. I have never really liked the single click to select and double click to activate idea that is in windows.
> I have KDE set up for doubleclick, so I dont dislike this behaviour, but you >are right - at least it should follow the settings in this.
That is my point. I want it to follow the system settings so that when you doubleclick it works the way you want it to and when I singleclick it works the way I want it to instead of doing its own thing.
> and you load a directory (wait 4 secs) every time you want other music? try
Well considering my playlists will play for hours and load in 4 seconds and that I will switch them maybe 2-4 times/day the 4 seconds does not seem to cost much. :)
>juk... just (double...)click a playlist (and you always see them on the left) >and it plays. if you want a simple and usefull interface, try juk. amarok is a >bit worse imho on usabillity (at least they should replace their playlist tab >with juk's playlist system, eg drag'n'drop, a collection playlist etc. whould >make it much easier).
I will look into juk again the last time I used it I did not like it very much either. All my music is arranged in nested directories so I really just want to be able to click on a directory and have it start playing the stuff in it and show all the items it found in a playlist so I can jump around in it. I don't ever actually save a playlist in any of these applications since I can't see a reason for doing it. Juk and amarok are both nice applications but they seem pretty heavy weight for what I want to do and many of the features in amarok at least get in the way of my using it.
I just want the media player to respond to keybindings so I can stop, start, pause, skip, next song, previous song etc from hitting key combos so I don't have to take my hands off the keyboard or click on that application to do that stuff. I want the playlist to be very simple and just load up a list of songs based on a directory structure and allow me to click on a song and have it start playing. I also want the playlist to be minimal enough that I can easily fit it on one of my screens all the time along with some other apps. Right now noatun can do all of those things and gives me no stability problems.
>I want the playlist to be very simple and just load up a list of songs based >on a directory structure and allow me to click on a song and have it start >playing. I also want the playlist to be minimal enough that I can easily fit >it on one of my screens all the time along with some other apps. Right now >noatun can do all of those things and gives me no stability problems.
I think you should continue to use noatun... if you arange your music yourself in directory's, dont want to shuffle songs from several directory's or an album-randomplay function, but do - well, just what you described, than use noatun...
I want to be able to choose music by band, sometimes by genre, another time by just an arbitrary set of things so I make playlists and use the searchfuntion juk/amarok have to offer. eg you type in "pink floyd" hit enter and it will only play songs matching pink floyd. in amarok I have a 'clever' playlist on 'electronic' music. only electro/trance/etc will be played if I hit it. Or I want oldies? yup, clever playlist for that. I never have to organise my music, just trow new songs in the mp3 map, and they will be added to the appropriate clever playlists. and I have several 'handmade' playlists, which I use, too... noatun can't do that, can it ;-) so - different player for different style of use...
>I will look into juk again the last time I used it I did not like it very much either. All my music is arranged in nested directories so I really just want to be able to click on a directory and have it start playing the stuff in it and show all the items it found in a playlist so I can jump around in it. I don't ever actually save a playlist in any of these applications since I can't see a reason for doing it. Juk and amarok are both nice applications but they seem pretty heavy weight for what I want to do and many of the features in amarok at least get in the way of my using it.
One way to do this, is put all the directories into juk, and use the tag guesser on all of them. (I'm guessing it's nested somewhat like mine is with artist or album being in there?) In that case, set juk's left colum to tree view, and then you can get to it by album, artist, genre.
>I just want the media player to respond to keybindings so I can stop, start, pause, skip, next song, previous song etc from hitting key combos so I don't have to take my hands off the keyboard or click on that application to do that stuff. I want the playlist to be very simple and just load up a list of songs based on a directory structure and allow me to click on a song and have it start playing. I also want the playlist to be minimal enough that I can easily fit it on one of my screens all the time along with some other apps. Right now noatun can do all of those things and gives me no stability problems.
Ctrl-Alt+ Left/Right go to previous/next songs in juk, and mapping things is quite easy with khotkeys (on another computer I've got windows + z,x,s,a to control volume, plus forward/next.) I think it maps to media keys, if they are in the layout by default. (Though usually they aren't by default, and you will have to mess around with the keyboard settings in kcontrol, or other tools)
I unfortunately, don't know of a way to show the playlist graphically, but, it should be easy for someone else to write a small monitor.
dcop juk Collection playlistTracks "`dcop juk Collection playlist`"
gets a list of files (with path) If you want title,
echo "`dcop juk Collection playlistTracks \"\`dcop juk Collection playlist\`\"`" | xargs --replace dcop juk Collection trackProperty {} Title
(for some reason it was being a bit annoying about directly using the results, and such, hence the use of echo, xargs and a |)
juk's dcop interface is quite nice in general.
Hopefully by holding the Ctrl key when clicking, as that is the standard way of doing it.
ctrl-clicking them.
Basic design: use the simple action for the most common task.
That´s why you don´t ctrl-alt-shift-triple-click to open.
The problem with CTRL-click is nobody knows about it, that why every other UI system in the world uses single click for select, double click for activate. And that's why we do it in amaroK. We don't believe in KDE's standards here.
>The problem with CTRL-click is nobody knows about it, that why every other UI >system in the world uses single click for select, double click for activate. >And that's why we do it in amaroK.
I have a couple comments for this. Windows does support single click to activate and you can use ctrl-click to select at any time. It has supported that since at least windows 98. More importantly when you use those settings the programs OBEY them.
You may find the doubleclick method to make the most sense for you however kde has that setting because there are people that like both ways and an app should respect the wishes of the person using it. If someone did not like the single click way they would have set their kde desktop to doubleclick for many other reasons already and if your app respected their settings it would work as it does now. However amarok does not respect these settings and so it is not consistent with the rest of the environment and in my view that lowers its usability. I have the system set to single click for a reason and I expect the apps to obey those settings. If I wanted doubleclick I would have set it that way. What is next having konqueror do double click in file manager mode even when the system is set to single click? Why don't we throw more consistency out the window and kde can just remove the setting and every app can figure out what it wants to do.
> We don't believe in KDE's standards here.
I have to admit that with this view I hope that amarok NEVER becomes a standard part of kde until that is fixed. It is important that applications respect the system since inconsistenty is even worse. What you are essentially saying is that in order for me to use amarok I have to remember that is works differently then EVERY other kde app that I have of which all the rest seem to obey those settings. What a wonderfully usable app to go do its own thing and ignore the system settings. Yeah that sure makes it more usable.
Standards are important since even if you could make your app slightly better by ignoring some of them you make the whole system far worse off as users have to remember how every application behaves. Having each application with a gui designed entirely around its task makes the system unusable if there are no standards. If you want changes made the correct way is to work with those that do the standards and kde and see if you can get changes made that you believe will help many applications and not just yours. If you are only doing it for your app since it is a special case then really consider what you are doing.
"Special cases aren't special enough to break the rules."
- The Zen of Python, by Tim Peters
Summarizing Kosh's message:
"You may find the doubleclick method to make the most sense for you, however kde has [a user-defined] setting because there are people that like [it] both ways and an app should respect the wishes of the person using it."
Which is a good point.
JuK does the same. Single-click selects and double-click runs
I accept your points. We are after the best possible interface for our users. The playlist is absolutely central to amaroK, it is vital it is easy and pleasant to use.
I believe we please a lot more users by going this route. For instance we have a lot of GNOME users now, one of our high vote bug reports is one for fixing systray usage under GNOME. Single-click would really annoy them.
However I believe that we must make this optional, so don't worry. It'll hopefully be the case soon that everyone will be at least satiated. Consistency is important, you are right. But you still have to weigh it against how the interface feels. Nothing is black and white.
Finally, we are happy in extragear, and have no desire to become the KDE-default media player.
Thanks for the comments.
You have it exactly backwards: Nobody knows about ctrl-click *because* every other UI system in the world uses single click for select.
Well this isn't exactly the case, if every OS used single click methods there would be a lot of people who would not figure out how to select listview items. The major players realise this. It's the same as the number of people who don't know about CTRL-C/CTRL-V and thus can only ever copy and paste if there are toolbar/menubar items for it.
When you hide interface like that a good number of people never find it. With something as important to amaroK as the playlist, it's central component, we can only offer a good user experience to all users by going double-click.
We don't want to annoy people, this is why we chose this!
How is double-click any less hidden? You know double click because you were told to use it, that´s all :-)
well, then, make it configurable by just conforming to the kde standard... then users can set it to doubleclick or singleclick in the kde config screen and you guys dont have to worry about it, and dont have to add another option in amarok.