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