Tag Archives: juk

JuK Supports Opus Codec (sort of)

I just wanted to drop a quick note that JuK, the KDE music tagger/player component of the KDE Multimedia Software Compilation, now supports playback and limited metadata editing of Ogg Opus audio files.

This requires support from some underlying libraries:

  • The Taglib library must support Ogg Opus audio to add the track to your JuK collection at all. At this stage JuK can’t load a file to play if Taglib doesn’t support it, even if the playback system (Phonon) would otherwise support it. Taglib also provides the metadata reading/editing so our support is only as good as that provided by Taglib. For instance, the bitrates all show as 0kbps for my current encodes. Taglib only supports Opus in git as far as I can tell, so JuK uses configuration checks to see if Taglib supports Opus. JuK will still compile if Taglib doesn’t have Opus support.
  • To actually playback Opus audio, Phonon must support playback. Practically speaking this means your Phonon backend (VLC, or gstreamer, normally) must support Opus playback. Both underlying libraries already have releases (VLC 2.0.4 or later; gst-plugins-bad) supporting Opus so this shouldn’t be too hard.

One caveat is that I’m not sure what mimetype will eventually end up being used in shared-mime-data for Ogg Opus audio (probably audio/x-opus+ogg or audio/opus+ogg). At this point Ogg Opus audio gets detected as audio/ogg so I simply check for .opus extension if this fallback mimetype is identified.

In case it’s not clear from my writing “Ogg Opus” everywhere instead of just Opus, JuK currently does not support Opus audio in other container formats (such as Matroska). However the Opus standard recommends using Ogg as the container for purposes of storing audio as files so this should be how you encounter Opus files in practice.

Desktop Summit 2011

For what seems like the umpteenth year in a row, events have conspired to prevent my attending Desktop Summit/Akademy. :( However, I did want to pass on my well-wishes for a successful summit, and hopefully some constructive interaction with our GNOME counterparts and other guests.

As for myself, work on KDE things has been slow of late, for the usual reasons: School, Work, and Kids/Family.

Even with that however, I’ve been reviewing a submitted patch for KSharedDataCache to add support for Mac OS X Lion, many JuK fixes have been contributed for KDE’s 4.7 compilation, and I have managed to get kdesrc-build into a more modular source code layout, which will allow me to eventually do things like decouple support for compiling Qt from the specific module name ‘qt-copy’, add support for other buildsystems for some KDE dependencies (e.g. autogen.sh-based) and more.

Luckily school will be over soon (perhaps for good, this time). I will also be moving to a different work location soon which may give me more time on an average day (though that is still to be determined!). Either way I’ll be continuing to plug along, even if I can’t meet up with everyone once a year!

Big update collection

Unfortunately I haven’t made any blog updates in awhile. I’ve been very busy between work and school (and I will likely spend this weekend working on a 20 page project that I’ve written 0 pages for ;). That doesn’t mean I have nothing to report though…

First off, I have renamed kdesvn-build to kdesrc-build to reflect the fact that it builds from Git-based software repositories. In conjunction I released kdesrc-build 1.12 which has various minor improvements, including a few Git improvements.

I’ve complained about my car breaking down. It’s fixed, although I will be selling it now (my wife and I were debating the merits of getting an improved car for awhile before, this incident sealed the decision).

Just today I’ve committed a new feature to JuK, the sadly neglected KDE Software Compilation music manager. Now you can use the scroll wheel in the track announcement popup to quickly switch tracks without having to use the Next/Prev buttons. It’s probably already in every other media player with a playlist, but it’s at least in JuK now. Note that this is a 4.6 new feature, not 4.5.

I’ve also been “reviewing” a patch to further remove Qt3 support code from JuK, which I will try to clean up and get comitted this release cycle. The big thing I still need to do is to finally convert from K3ListView to a real Model/View architecture to finally be rid of Qt3Support. Help is always appreciated btw =D

Burkhard Lück, the documentation super-hero, has been improving JuK documentation for me, but I still need to make some changes that he’s requested to bring the docs closer to 2008-era (let alone 2010) :(

That’s another good “intro to KDE Platform” kind of job by the way, it’s how I got introducing into coding for JuK myself. ;)

Keep moving

So, I’ve been trying to keep working and moving and generally being productive. It helps me feel a bit better and besides, it’s easier doing something than to do nothing.

Since the most distracting type of “doing something” for me is coding, I set myself the task of changing the system tray icon implementation for JuK to the newly-added KNotificationItem. This was involved enough in JuK’s case to be worth doing without being so involved that I’d get fed up. It was a nice distraction for a day.

I noticed that the KDE 4.3.1 release was dedicated to the memory of Emma, which is something Mary and I appreciated.

I went back to work last week, but it was too early as it turned out. I tried again yesterday and it seemed to go better so I think I’m on track to resume my qualification process for instructor duty. Obviously the support provided to me by my command has been invaluable in helping Mary and I get through the grieving process.

I had (finally) informed our bank/insurance company of Emma’s passing last week. I received a package in the mail from them yesterday, but with no forms or anything to fill out, just a short letter and a short pamphlet. Kind of a nice touch, I thought. The pamphlet mentions that the grieving process begins after the shock, numbness, and disbelief subside. In my case I know I’ve been grieving and I know that Emma is gone and yet depending on what I’m thinking it still doesn’t “register” sometimes that she is dead. It’s gotten to where it feels more eerie than painful but it is still disconcerting to simultaneously know that your baby is gone and feel that she is right there.

I also finally got around to moving some of our broken-down cardboard boxes to a recycling facility. I had thought it required showing up during business hours, which is difficult when those hours coincide with my working hours. And I didn’t feel like doing it when I was on emergency leave somehow. But it turned out there are collection facilities where you can just drop it off at your leisure, so now our garage has much less crap in it.

I am in graduate school now so although I will be trying to increase my programming-related activity if only for my own peace of mind, I’m not sure how much of that time I’ll be able to contribute to maintenance of my current KDE projects (as few as those already are). kdesvn-build will probably be my priority due to the shift (someday) to the Git source control system and because few KDE coders are familiar with Perl. (Even if kdesvn-build gets obsoleted I hear there is another possibility being worked on by a different Michael…)

I’ll probably try to blog more often as well. I usually feel better and I used to post entries quite frequently (when I was in college and had tons of time at least!)


So Aaron had a post up about building a community. A couple of the major points he is driving is to make it easy to work on the code, and to make it easy to contribute. In accordance with those principles I have been continuing to work on kdesvn-build as I feel that being able to quickly get into a working KDE development environment can open code review and contribution substantially.

Dominik Haumann also mentioned kdesvn-build and wondered why it is not more prominent in the KDE TechBase build instructions. I’ve not done it because a) I want to avoid “tooting my own horn” so to speak and b) the ever-insidious lack of time. I (obviously) think kdesvn-build is a swell way to setup and maintain your development KDE environment so if people would like I can try and post up instructions on the TechBase.

As far as kdesvn-build goes, I’ve fixed a bug (bug 172719) preventing successful builds of a module if you had more than one option in your cmake-options for that module. In addition I’ve extended support for KDE Subversion module snapshots to modules from extragear and playground, which will help for initial checkout speed.

I’ve changed the handling of the “tag”, “branch”, and “module-base-path” options. They used to automatically add the module name to the end of the generated URL before checking out the module. This was because the way we had Subversion branches and such setup initially always seemed to have an extra module name in the path, at least for most modules. Now that is not the case, so although it is an incompatible change it is time to move on with the times. (I have added a warning for this specific change if kdesvn-build thinks you may be affected by it so you should not be caught unawares I hope). I’ve also been working on finally adding a test suite for kdesvn-build since there are so many features now that I need a way of making sure I don’t break the software by accident from a seemingly minor change.

I haven’t forgotten about JuK either although I’ve not been able to accomplish anything close to what I’d like. For KDE 4.3 the track announcement popup will use XCOMPOSITE extension if available for true transparency. In addition I will at some point make the crossfading optional since it’s kind of a love-it or hate-it thing for many people. I’ve added some more errors checks although I don’t know of any specific bugs that they will fix offhand.

As far as the soon-to-be-released KDE 4.2, I managed to add a new KDE screensaver (the KDE Asciiquarium that I’ve mentioned before). In addition I’ve added a kioslave for Perl documentation and made the man kioslave output more presentable. For KDE 4.3 I would like to condense the stylesheets and such split between the various documentation viewer kioslaves into a common set but we’ll see if I get time. It would make a good junior job I think though if anyone is interested. ;) Also the info kioslave still needs to get transitioned over.

Hopefully that won’t be the extent of my contribution to 4.3 (other than the normal assorted bugfixing) but we’ll see, it just depends on the extra time I get (and that keeps going down as the little one keeps getting older ;).

Here I go again

So by the time you read this I’ll be deployed again.

Unfortunately even as demanding as our refit environments normally are this was more demanding than most. I’ve had a few bugs in the latest kdesvn-build releases reported (172635, 172696, and 172719). Not all of the bugs were regressions but it appears that despite my best efforts 1.7.1 is a buggier release than I would normally find acceptable. And of course JuK continues to float by almost on life support.

Even given all of that however, I think I did manage to get a lot done during this in-port period. KDE is already working on the 4.2 release with a few non-JuK, non-kdesvn-build improvements which I got included including some kioslave improvements and a new screensaver. JuK itself did see some love although not as much as I’d like. So I think I’m satisfied with what I’ve accomplished.

Please note that software like kdesvn-build is by definition unmaintained unless some kind souls want to keep it going while I’m out. I can’t tell you when I’ll be back (although it obviously won’t be forever) but Perl isn’t quite as bad as it’s made out to be and besides that I’ve tried to deliberately use easy-to-read coding style in kdesvn-build to make it maintainable. I’ve also disabled my mailing lists and Bugzilla email. I will email an address that may work separately to Thiago Macieira if it is urgent to reach me, just keep in mind I may not be able to reply back depending on the ship’s schedule.

So while I’m out working hard please keep yourselves safe and keep truckin’ on KDE work. KDE 4 is looking great and I’m looking forward to being back to work on it. There is a rumor this may be my last patrol. No definites unfortunately but until you have orders to your next duty station in hand, nothing is definite anyways. I’m leaving comments enabled so if you see spam start to pop up in the comments I apologize and I’ll fix it when I get back.

Improved crossfadiness

So I’ve made a few more changes to the crossfading code in JuK. This should hopefully fix crossfading issues completely for people. However, life is weird sometimes. phonon-gst went from being completely unusable (it would crash with JuK) to being the best option right now (perfect crossfading, at least here). phonon-xine, due to the way crossfading is now implemented sounds slightly crackly sometimes while playing music back. Even with the new crossfading routine, incoming music starts out at a high volume before fading in, although it does sound smoother.

Basically what used to happen is that JuK would pipe the music directly from the file to the Audio Output object. Phonon allows you to insert effects into that audio path, which is how crossfading works. You simply start playing the next song with a fader effect, set to fade in, and at the same time insert a fader effect into your currently playing stream set to fade out. Unfortunately phonon-gst has issues with removing effects from an audio path it looks like, which is why I was getting crashes. Even when I fixed the crashes by simply leaking the object as an experiment, the crossfading was horrid under phonon-gst as it takes seemingly forever to setup the fader and insert it into the audio path.

So what I’ve done is to simply insert the fader effect into the path from the start, and simply tell it to fade at the right time. Presto! Except that doing this seems to cause artifacts with phonon-xine output sometimes… *sigh*. But for now now it looks like phonon-gst has gone from unsupported to the best option for JuK at this point, hopefully all the backends will work equally well by KDE 4.1 though.

In other news, kdesvn-build in /trunk will allow you to build the Phonon pseudo-module. I say pseudo because there is no phonon module. It is developed in kdesupport. However I’ve been informed that the correct place for most users to build phonon from would be /branches/phonon/4.2. kdesvn-build has a couple of hacks that would support pulling it from the right location but still wouldn’t be able to build it due to the module layout. So I’ve added a bit of special support for it. I also changed the sample rc file to show how to build Phonon 4.2. If it’s important enough I’ll go ahead and make a 1.6.1 release.

Is there anyone looking forward to C++0x more than I am right now? :) The linked Wikipedia page has tons of changes, some which worry me a bit due to syntax (for example, lambda functions). Then again, I’ve never seen a good syntax for lambda functions, although I’m sure it’s just me.

But things like an auto keyword to allow for automatic type deduction? Very nice. For example, instead of doing:

for ( QList<QWidget *>::ConstIterator it = list.begin(); it != list.end(); ++it() ) {
  // use *it

you could do:

for ( auto it = list.constBegin(); it != list.constEnd(); ++it ) {
  // use *it

I did have to change begin/end to constBegin/constEnd to make sure that the non-detaching forms of the iterator are used, but this may be something that g++ is able to deduce as well someday.

Probably the biggest other feature I’m looking forward to is the “rvalue references”, which will allow for constructors that “move” data instead of having to copy them over. Qt has kind of mitigated the problem somewhat in their shared classes but you can benefit from this even in non-Qt-using code. There’s many other improvements too, I just wonder how long they’ll take to get into a g++ which we can use for KDE development. :)

Improved crossfading

I’ve been improving JuK a lot over the past week or so trying to get it into better shape for KDE 4.1 (and 4.0.5).

What I’ve worked on today was the issue with crossfading where the volume differential between the songs would go haywire initially. I think I’ve got it as good as I can get it from JuK, but now there’s something else I need.

I have posted an email to kde-multimedia detailing my problem, but basically I want to use the gstreamer phonon backend to test whether the problem lies with JuK or with phonon-xine.

The first problem was that JuK wouldn’t work with phonon-gst because JuK made some inaccurate assumptions about when Phonon would actually start playing after being told. (Hint: Not immediately, the backend has to setup first).

That is fixed in both the 4.0 and trunk branches now. But when using phonon-gst to playback a song, any time I switch to the next track JuK crashes on an assertion in phonon-gst. This happens even if I do not allow crossfading. This does *not* happen if I slow it down in gdb by single stepping. So I think it’s a timing issue.

Anyone out there use phonon-gst and could tell me what I’m doing wrong?

Amazon MP3

So I’m a pretty big fan of the Amazon MP3 Music Store. It has had very few tracks which I wanted to grab which weren’t available. It’s cheaper than the iTunes Music Store as well. I realize this is the case only because the music labels are tired of getting their terms dictated to them by Apple so they decided to open up the competition and make the deal more enticing. But that works in my favor so that’s awesome. Only thing I’m afraid of is that that music labels will try to do something dumb and try to start adding DRM copy protection to the music again (which breaks the music on my players). But anyways, back to my original point: Amazon’s MP3s even come with the cover art built-in to the track.

I noticed this when I tried playing some of my purchased tracks on my laptop this past underway with Amarok, and noticed that it displayed the cover art just fine. After a bit of work now that I’m back in port I’ve managed to add display of built-in cover art to JuK as well. The patch is available as an attachment to KDE bug 103118. In addition (what the bug was reported against) if no cover is present JuK will look for cover.jpg in the same directory as the music file like many other media players do. No screenshot, it looks just like normal JuK cover art support, only JuK pulls from more sources with the patch.

As far as where this lands I’ll have to email core-devel. I returned to port way too late for the 4.1 feature list :) so this may have to wait for 4.2 (depending on how much toward “bugfix” people are willing to lean). But if people want to test that’s fine. ;)

On a related note, if you’ve been using JuK and notice a bug that is egregrious (i.e. you can’t even play audio because JuK always crashes when you click Next, you can’t add files, etc.) please leave me a comment so I can prioritize. I have limited time so I’d like to make good use of it in time for KDE 4.1.

I already know of the fact that you can’t seem to drag-and-drop tracks to playlists anymore for instance (which hampers my routine at least so I’ll try and fix that soon).

KDE 4.0(.0)

So at long last the first release in the KDE 4 series, KDE 4.0 has been released.

A couple of days after they tagged 4.0 I switched to using KDE 4 as my working desktop. (btw, isn’t it odd that the tag name is 4.0.0 if the release was called 4.0?)

It was remarkably more stable and usable than it had been just 4 or so weeks before when I had tried it last. I managed to fix a couple of JuK bugs (one very minor, another a crash) before 4.0.0 was tagged. Unfortunately I didn’t get time to do nearly enough testing so JuK as shipped with 4.0 has several bugs which are already fixed, including:

  • Allow JuK to load the playlists and cache for KDE 3’s JuK (so you’ll need to wait for 4.0.1 to load your old collection. Sorry. :( )
  • Correctly save the collection list after running JuK for the first time (so you’ll need to wait for 4.0.1 to save your new collection. Sorry. :( )
  • JuK files in 4.0 will not be compatible with 4.0.1 due to the bug that prevented loading 3.5 data. But if JuK fails to load the files it will try again in a mode that should allow 4.0 files to load, so fret not.
  • Some icons that used to show up had their names changed and I didn’t update JuK. Fixed in 4.0.1 and greater.
  • I fixed a bug causing the Play Queue to show up twice on startup, and it was pretty random as to whether JuK would save whether you wanted the Play Queue shown or not on shutdown.
  • The track announcement popup is pretty much completely hosed in JuK. I would disable it until 4.0.1, which has bugfixes for cover icon size, and track popup positioning.
  • I fixed a bug where the list of playlist columns you wanted visible was not saved properly.

All of these issues are fixed in the 4.0 branch (what will be 4.0.1) and in trunk (4.1). There is still a bug where the History Playlist doesn’t have the extra “Time” column that it is supposed to have (and I’m not sure why it doesn’t). And of course JuK is still a little rough around the edges. But it is good enough for daily use I think even though the underlying code could probably still use some porting love on my part.

If you use kdesvn-build then it is possible to build the specific 4.0 release (using the tag 4.0.0 option pretty much everywhere) but I would recommend building the 4.0 branch instead if you’re going to be going to the trouble of using kdesvn-build. Especially since from what I under Gary L. Greene will be porting Konstruct to work with KDE 4 tarballs. Tarballs are mirrorable and put much much less load on our SVN servers. :)

Also I plan on pushing out the next kdesvn-build release at some point soon. kdesvn-build in /trunk supports downloading module updates while building which can be an impressive speedup. It introduces a few (minor) bugs which I may not have time to fix before I must release it or wait but I think the net benefits will be worth it.

Back to KDE 4 though, I wasn’t sure if I liked kickoff KRunner (the new Alt-F2 Run Dialog) but when I went to try and launch System Settings, as soon as I typed “system” it noticed what I was trying to type and brought up an entry to launch that program. Very helpful.

(Incidentally the reason I was doing that was to test switching cursor themes. I heard that in KDE 4.0 it worked without requiring a reboot of the X Server, and it worked for me so that’s pretty cool.)

So congrats to all the developers, testers, translators, artists, bug wranglers, marketers (I guess we have those now ;) and everyone else who worked so hard to pull of the next major release of KDE. I’ll try to keep doing my part (time permitting unfortunately).