XMMS2

Proof of concept code for LADSPA hosting is now up in github. This code is still very inflexible, as you can’t even select the plugin you want to use (it uses a simple gain plugin amp.so, sorry oneman!), but it shows a working LADSPA host, which can ... [More] take parameters from the server config. If you try it out, you will be able to modify the gain by using: nyxmms2 server config ladspa.parameter0 1.0 Where the last number is the gain value for the LADSPA plugin. This xform plugin accepts both S16 and float samples, and creates internal buffers to pass to the LADSPA plugin. If you have a look, there are still many TODOs, but most infrastructure is there, even to support multiple LADSPA plugins within the same xform. I had done a LADSPA host before, so I tried first to write the host from a quick look at the LADSPA header. This turned out to be a bad idea, as there were many small details and problems which I could’ve avoided by reading some documentation like: http://gdam.ffem.org/ladspa-doc/ladspa-4.html In particular it is important in LADSPA to remember to allocate buffers for all ports (both audio and control), even the ones you are not going to use. One of the challenges now is deciding how to handle different channel counts between the chain and plugins, and try to get input from the xmms2 devs regarding a way to define config properties from the init function rather than the setup function. Most xforms are OK with setting their properties in setup, but a LADSPA host definitely needs to register the config properties in the init function where the plugins are initialized. It should also be able to dynamically create and delete properties in case the plugin is changed in the middle of a song. [Less]

I got my welcome package (pretty pathetic but nice notebook, pen and sticker again) from Google and the GSoC has officially started this Monday. This means I should write some kind of list for myself to keep in order what I am going to do in the near ... [More] future and in which order.The most important feature is the channel mask that is missing and this will require a quite big commit. There are also some strange things that are working, but are a bit weird. For example the pulse output plugin doesn't set any XMMS_STREAM_TYPE_FMT_CHANNELS in its goal types (quite recent change) and xmms_stream_type_coerce skips all the output goals that don't have XMMS_STREAM_TYPE_FMT_CHANNELS. Looking at the code, nothing should be selected as the best option, but I'm missing something and a goal type gets selected anyway. I'll run it through the debugger just to find out what am I missing here.After I've figured out how the output goal type is selected properly I should add XMMS_STREAM_TYPE_FMT_CHANNELMASK to the headers and streamtype.c. It should be noted that some places use XMMS_STREAM_TYPE_FMT_CHANNELS but they don't have to care about XMMS_STREAM_TYPE_FMT_CHANNELMASK, because they only want to know the number of channels. Those two should probably have to be kept in sync somehow though. I think this should be enough work for a while, and I would really want to have a usable patch to be pushed upstream before starting to work on any of the other stuff. (multichannel wav files, converter) This is the basis of most of the multichannel support anyway. [Less]

Yesterday was the official start of the GSoC program! We had some nice ideas about my proposal during the Community Bonding Period and documented them in a dedicated wiki page. And now it’s time to put them to practice. I started coding the server ... [More] object described in the last section of the wiki page yesterday, and also made some progress today. I’ll have some code to show in the next few days. And before I forget: last week I copied over the official XMMS2 development repository to a repository of my own in Github, which is where my changes will end up when they are a little more mature. I’ll also update the wiki page with the issues I encounter and necessary clarifications as I go. [Less]

I think I'm doing like 12 hour days on this project and multichannel already came into my dreams today, but can have a rest after a while. Today I worked on finding out about AC-3 and DTS decoders that are common formats for multichannel audio. ... [More] Adding AC-3 was pretty straightforward using the avcodec plugin, but it did have a small problem in that it required full frames while avcodec plugin occasionally provided partial frames. This was not a big deal and avcodec plugin needed cleaning up anyway.Adding DTS should be quite easy using the avcodec plugin as well, but another problem came up in addition to the partial frame issue. The ffmpeg DTS decoder was buggy and didn't return the consumed input bytes correctly, instead it always returned the input buffer length. The correct frame size value is always in a fixed offset in the DTS headers so parsing it in the avcodec plugin wasn't that big of a deal, although it is hacky.I also noticed there was a new bug 2437 in mantis saying that the avcodec plugin doesn't compile with the latest libavcodec version. I found out that the libavcodec version 53 has changed the API again and CODEC_TYPE_AUDIO is now AVMEDIA_TYPE_AUDIO. Slightly bigger change was that function avcodec_decode_audio2 was changed to avcodec_decode_audio3 with different parameters. This is already the second time avcodec_decode_audio has been replaced during the lifetime of avcodec plugin, that's pretty good for a function that only takes 5 parameters. Make up your mind already ffmpeg guys... But I wrote the backwards compatibility macros and now avcodec plugin should compile cleanly with all libavcodec versions again, yay!Problem when playing the files was that channel mapping in pulseaudio was wrong, I patched it to use mostly the channel mapping introduced in last blog post, including some sensible defaults for each channel number. I will write more about those defaults later, but they follow quite closely the channel assignment of FLAC.So long story short, XMMS2 avcodec plugin now compiles with all libavcodec versions and supports AC-3 and DTS and pulse output plugin handles multichannel audio nicely. Hopefully available in upstream soonish. [Less]

It's time to start the project again and since I'm afraid there might be some personal things keeping me busy in the summer I'm getting a head start. The idea of the project is to get multichannel working WELL in XMMS2 music player. There are several ... [More] patches around, but they're partly conflicting and need cleaning up. I will start with the multichannel support and the also included higher quality resampling will be handled later.One of the most difficult issues in multichannel handling the channel order. As weird as it sounds, there is no standard for channel order and everyone basically uses what they wish. After looking through a lot of options I've come to the conclusion that we should definitely be using the channel order described in Microsoft documentation combined with a channel mask. As the Microsoft website already says "Several external standards define parts of the following master channel layout". The motivation is further explained below.First let's take a look at most common multichannel audio formats and their 5.1 channel assignments (FL=front left, FR=front right, FC=front center, LFE=low frequency effects, SL=surround/back left, SR=surround/back right):WAV/MP3/FLAC: FL, FR, FC, LFE, SL, SRDTS/AAC: FC, FL, FR, SL, SR, LFEAC3/Vorbis: FL, FC, FR, SL, SR, LFEAIFF: FL, SL, FC, FR, SR, LFEThe most popular formats in surround files according to my own experience are FLAC, AC3 and DTS. The suggested channel layout will work with FLAC 5.1 files without any changes, but for example for FLAC 4.0 files the center and LFE channels need to be masked out with channel mask. The DTS and AC3 channel assignments are not supported by any known output and require remapping in any case. This should be easy to do in the decoder anyway.Then we need to have a look at known audio systems, their corresponding default channel assignments for 5.1 channel audio are as follows:ALSA: FL, FR, SL, SR, FC, LFEOSS4: FL, FR, FC, LFE, SL, SRMacOSX: FL, FR, FC, LFE, SL, SRWin32: FL, FR, FC, LFE, SL, SRPulse audio can easily handle all of these configurations and has channel remapping included, so we can leave that out of the calculations. It is quite clear that ALSA is different from all the others and there are quite good reasons for that. First of all ALSA as in most outputs includes support for user configured channel order, so the order can be changed in ALSA configuration. More importantly with the ALSA channel mapping it is possible to output 4.0 quadraphonic audio without any channel masks, because the first four channels are identical. However going with the rather non-standard (although de-facto standard in Linux) ALSA channel mapping is not worth it if we want to do things cleanly.If we compare the two lists, audio format channel order and audio output channel order, it is quite easy to notice that the suggested channel order has most similarities in both and we can do out without channel masking. It should be noticed though that this is only true with 5.1 audio, if we want to include the mentioned 4.0 audio we need to have a support for channel mask. That means that some channels can be masked out of the audio stream and therefore ignored.I hope this is good enough introduction to multichannel audio, I will get back to it later when I will introduce how it will affect the converter and what should be done there. [Less]

Basic skeleton for the new xform plugin is now ready: https://github.com/mantaraya36/xmms2-mantaraya36/commit/133838c34fb617e05e8062a97b9f0ac21188462a#commitcomment-381216 Daniel has spotted some minor issues with indentation which can checked with: ... [More] http://people.xmms2.org/~andersg/indentcheck-v5.py and be fixed by using the proper emacs script and has pointed me to the way Changelogs should be named for XMMS2: http://xmms2.org/wiki/ChangeLog_Format Also set up emacs to format sources correctly from: http://xmms2.org/wiki/Emacs_C_style I had never added an elisp file manually before, so I followed the instructions here: http://edward.oconnor.cx/2005/09/installing-elisp-files Which say you can create a directory to place your elisp files: (add-to-list 'load-path "~/elisp") and then you can load the elisp file in the .emacs file. It seems to work… [Less]

I’ve set up a repository where I’ll be doing my work at: https://github.com/mantaraya36/xmms2-mantaraya36 And I’ve now finished setting up emacs for my first real-world usage of it after several months with QtCreator. Finally got CEDET and ECB ... [More] installed and now emacs starts making sense as an IDE. Had a quick look at how waf is set up and I think I get as much as I need for now… Also, reviewing XMMS2_Coding_Style. Might be nice to figure out how to integrate waf into a CEDET project… but I’ll probably end up just having a separate terminal for building. The first thing I’ll get into is writing a proof of concept LADSPA plugin loader  to get acquainted with writing xform plugins. This is where I’ll get started: http://xmms2.org/wiki/Writing_XMMS2_Plugins http://xmms2.org/wiki/Notes_from_developing_an_xform_plugin [Less]

I have been accepted by XMMS2 as a student for GSoC this year! My proposal is to implement Service Clients: basically, clients that can offer functionalities to other clients by exposing methods for remote calls. This is actually a long-standing ... [More] idea, and there’s even an incomplete implementation already. It will be very interesting to see all sorts of crazy services popping up after I’m done with my project… Stay tuned! [Less]

GIMME, originally developed for Google's Summer of Code in 2010, is a well-rounded XMMS2 interface for GNU Emacs that provides a minimalistic and intuitive user experience through searches, powered by collection operations. It works very nicely, but ... [More] still lacks the polishing top-quality Emacs packages have, modern features other interfaces have and a userbase. I propose to work on all of these issues in this summer, and after briefly presenting these features in terms of deliverables, I'll present a schedule of things to done. I. First things first. Trees' format. Multiple buffer support. The playlist-updated broadcast. II. New important features. Kill/yank on regions. Advanced tag writer. New collections' format and parser. Operations directly on tree-view. Prepare it for Ruby 1.9. III. Interface polishing. Better auto-completion. Emacs' plugins. Colors. Playlist presets. Spectrum. Standalone. IV. Less important new features. Updating collection. Plugins and configuration. Equalizer. gimme-lyrics. V. Creating a community Screencasts. Wiki and list. Marketing. Packages. ELPA. VI. GIMME's new modes. faceted-view. augmented-mode. VII. Code Polishing. Faster. Process. Bug hunting. I. I'd like to start with first things first. Last year, tree-mode, a way of displaying nested collections, was the last part to be coded, and although it works, I discovered too late that collections were not to be represented as id lists but as their search tree, i.e., I was treating them statically not dinamically. This is the first thing I shall fix. I'll expand, then, the tree-mode into bookmark-mode, to be used more extensively later, and add multi-buffer support to GIMME, a new feature that is present in modern packages like notmuch, an e-mail client, and ERC, an irc client and which navigation more pleasant. Because I don't use it in GIMME, a callback function that deals with move operations was left incomplete, and I'll use another client to test and fix that. I plan on doing all of this in three weeks, roughly one to fix the trees' format and two for multi-buffer support and other minor features. II. Development will continue upgrading the copy/paste support. On GIMME, instead of moving files around, one can copy and paste them around as if they were text. That operation actually uses the clipboard, so it is possible to copy and paste a song you are listening to in an instant messenger and let your friends know what you are listening to. AFAIK this feature is unique to GIMME, I will expand it to allow copying and pasting multiple tracks in a region. As GIMME's operations are mostly asyncronal, this is not done by doing the same operation on multiple files, and will involve tinkering multiple queries. I'll add support for the new collections' format, and write the bindings to use vdust's collection parser, taking some time to properly integrate its completion mechanism with Emacs. With the trees properly fixed and with GIMME supporting the new format, I'll add the feature of manually combining collections with the usual operations, such as AND and OR. A last feature will be implemented in this part: a mass tag editor that works like this. Then, I'll work on supporting Ruby 1.9, a new version that breaks a lot of things including a library I use. I've already fixed it, but until the mantainer accepts my patch, I'll explicitely publish a workaround in the documentation, with instructions on how to install GIMME in the major distributions of GNU/Linux. Again, I plan to spend 3 weeks on this part. III. By then, I'll spend some time focusing on how GIMME can interact more smoothly with Emacs. I'll complement the auto-completion functionality provided by the new collection parser in the Emacs side, too, testing well-known packages such as anything and ido to do the job. Tramp, is a file manager for Emacs, and it should be used to add files to XMMS, since GIMME works only with files already on Mlib. Adding directories recursively is also necessary, and I'll investigate what other operations I can integrate on it and implement them. I'll also upgrade the status-bar to add an optional spectrum analyzer like this one. Not less importantly, I will work on color schemes and playlist formats, more eye-candy to impress new users. Finally, I'll rewrite GIMME so it doesn't presume XMMS is installed. A new user will be able, then, to install the Emacs package and from there figure out what to do. This phase will take two weeks. IV. Less important features will be developed now. A lot from XMMS is still inacessible to the user, and in this phase I'll work on that so he won't have any reason to use an auxiliary client, such as nyxmms2. First of all, the user must be able to rehash or update his collection from Emacs. Then, interfaces to change XMMS configuration, check out what plugins are and aren't there and get detailed information of a track will be added, as well as an interactive equalizer. I'll add support for lyrics lookup, too. This will take one week. V. I'll work on GIMME's community and sustentability in this phase. How to keep development going? By fixing bugs and adding features, as requested by the users. Already with an uservoice page as well as an introductory one that also works as a wiki, I'll create screencasts presenting GIMME's features to the world. Basically, there will be one per feature. I'll also write some extension information in the wiki. I'll create a mailing list for GIMME and make it known in Emacs circles, such as #emacs on freenode and its reddit page. Finally, I'll make sure GIMME will be in ELPA, Emacs' package repository, and hopefully create a package for Archlinux and Debian. This will two weeks, one for packages and infrastructure, and another for the marketing and screencasts, although these can and will be released incrementally as features get ready. VI. Searches rule, yet sometimes we feel like making some sense out of our collection. I will develop faceted-view, which extends filter-view, the search-like view, by clustering together similar songs as you filter them, somewhat like how this plugin works. I'll also develop augmented-mode, a system that allows querying freebase to do fancier searches, such as "GIMME the top songs of bands that influenced the artist whose song I'm playing right now". I'll implement a couple of these searches that make sense, but primarily work on the library, as the possibilities are endless from here. This will take two or three weeks. VII. Intensive bug hunting and intensive bug fixing are the keywords of this phase. I'll spend a whole week doing that. After that, I'll work on performance and elegance of the code. I'm not totally convinced that the way the Ruby part talks with lisp is good enough for large collections, for example. I'll investigate that and how another elisp package deal with processes, as GIMME's are systematically destroyed every time an user invokes it. This will take two weeks. [Less]

Map application. If you like photos and Flickr, then you gonna love Flickr Wallpaper. It turns your desktop into a live slideshow of great photos from Flickr. ★ Flickr Wallpaper ★