Saturday, October 08, 2011

Goggles Music Manager 0.12.4

  • Added Portuguese Translation by Sérgio Marques
  • Improved notification daemon compatibility
  • Support for latest FOX 1.7.29.
  • Added genre and location to mpris information.

Wednesday, September 28, 2011

Album Covers: Now less sucky!

Goggles Music Manager 0.12.x currently features an album list with optional cover display. The cover display can be turned on from the preferences and displays a list of albums with a small cover image of 64 by 64 pixels. Here's what it looks like:

For certain cases it may work OK, but in all honesty it does come with some serious drawbacks:
  1. The cover image is rather small. For some people it may be just the right size, but often times I have wished they were bigger. For example, on larger displays like my Home Theater PC, they are barely recognizable. Browsing through your collection by cover is more fun when they're bigger.
  2. With the covers shown, it takes up a lot of useless vertical space. As you can see in the picture, for each item the image takes up the most of the vertical space (3x) with the text centered in the middle. The 'space to information' ratio is rather big. With wide screen displays being more prevalent, we really want to avoid taking up so much vertical space. Increasing the size of the cover would make it only worse.
  3. Covers are loaded in a non-threaded approach which makes the UI sluggish while the covers are loaded at start up. Depending on the number of covers this could take a long while and may consume lots of memory.

Threaded Cover Loader

So obviously there was room for improvement and the first issue I fixed some time ago was loading the covers in a background thread. This was made possible when I implemented the necessary infrastructure to move the importing of music to a background thread.

Every time the database is updated, it will automatically start the cover loader. It fetches covers for each album from disk, re sizes them and stores them in the cover cache. Once it is finished it notifies the UI, which then can display them.

Matrix View

The next change was to replace the list view with a matrix view. The list is still available, but doesn't show any covers. Here's how it looks:

The matrix view takes full advantage of any available horizontal and vertical space. As you can see the artist and album title are underneath the cover. Depending on the font size this may not always show the full name or title, but a tool tip with the complete info is available as well.

One detail I wanted to mention is that the cover loader will automatically apply cropping to a cover if it is close to being square.

Performance & Memory

The matrix view in combination with the new threaded cover loader worked pretty well for small collections. But with large number of albums, creating pixmaps for each of the covers took an awfully long time. What made it worse that this was happening in the UI thread.

I was able to optimize the pixmap creation by combining multiple covers (64) into one pixmap. (for 500 covers that means you only need to create 8 pixmaps instead 500). This seemed to work well, but I hadn't thought about memory consumption yet.

Recently a user was complaining that gogglesmm was using memory in excess of 130MB. Yes, that was over 2000 covers (uncompressed) in memory. That definitely made me rethink my approach of maintaining the cover cache. After all, for drawing purposes we only need to have the pixmaps in memory that are visible on screen.

I changed the cover cache so that all covers will stay compressed in memory until they are ready to be drawn. At the moment that the cover needs to be displayed, it gets uncompressed and transferred to a pixmap. Pixmaps get reused so in most cases you only have about 12 to 16 pixmaps in memory.

Initially I was concerned that decompressing  and updating the pixmap from within the drawing routine would be too slow, but surprisingly I hardly noticed any slow down. Granted, this is on Intel Core2duo laptop (couple of years old) but I'm quite hopeful this will work on more ancient hardware as well.

Last but not least, if you're not interested in seeing the covers, you're no longer penalized by it. The cover cache and loader will only be loaded if the cover view has been activated.


Right now the cover size is fixed to 128 by 128 pixels. I'm probably going add a setting to change size of the cover. 

Tuesday, August 16, 2011

Goggles Music Manager 0.12.3

  • Enable support for non-power-of-two textures now that Mesa 7.11-rc4 fixes the issue.
  • Fix incorrect usage of FXAutoPtr.
  • Fix parallel build.

Monday, August 15, 2011

Development Update

It's been a while since my last post in June. Quite a few things has happened since then.

Goggles Music Manager:
  • Dropped support for FOX-1.6. Need at least FOX-1.7.28.
  • Dropped support for XineLib.
  • ReplayGain not stored in the database anymore. This is now fully handled by the player backend.
  • Next/Prev button in the track editor to easily switch to next or previous track while keeping dialog open.
  • Need at least FOX 1.7.28
  • Meta data now gets parsed and forwarded to the frontend.
  • Replaygain support for flac, Ogg Vorbis and mp3 (lame, id3v2).
  • Redesigned the end-of-stream handling:
    • The decoder now only sends a end-of-stream notification to the output thread. No message is send to the frontend.
    • After receiving a end-of-stream notification, the output thread enters "drain" mode. Since potentially no data packets will arrive anymore, the output thread needs to wake up every so often to check the status of the playback buffer and update the position and time display.
    • In the output thread a timer is set to notify the frontend whenever the playback is almost done. (currently 1 second).
    • If no new stream is opened, the output thread will automatically close the output device and notify the input thread as well.

Morlocks on the Beach

Jeroen van der Zijp, creator of the FOX toolkit now has his own blog. Check it out!

Thursday, June 09, 2011

Upcoming Changes

Here's a heads-up for those who follow the latest development version of gogglesmm.

I've decided to retire xinelib. It has served us well in the past, but its time has come to be replaced by GAP (Goggles Audio Player Library). Of course, it means we do lose some functionality in the "short term", but hopefully, with the help from other people, missing functionality could easily be added. I do feel we have most of the major functionality available in gap: reliable ogg/flac/mp3/mp4 playback including internet radio streaming. As a matter of fact, for the last year I've haven't used the xine-backend at all.

With the retirement of xinelib, we also can get rid of the libcurl dependency. It was used in the past to download pls/m3u filetypes since those weren't handled by xinelib itself. GAP handles these files without any problem. There's still a chance we may use libcurl again whenever we decide we want to add a podcast manager.

I'm also dropping FOX 1.6 support. Simple reason is that GAP requires FOX 1.7 and I'm not planning on backporting it to FOX 1.6. I also made the last FOX 1.7 release (1.7.26) the minimum required version since this shipped with a renamed pkg-config file (fox17.pc instead of fox.pc) and is also the start of the new BGRA support in FOX. I was able cleanup the source code very nicely and remove all the unneeded ifdefs!

With GAP being the primary playback engine, we no longer need to store the replaygain in the database. I'm planning on GAP being able to read any replaygain tags directly and apply them during playback. So you will have to re-import your music into the database due to the changed tables.

Goggles Music Manager 0.12.2

  • Gnome 3 compatibility updates
  • Fix infinite warnings when the system time is out of sync with the server time.
  • Merge title that were split into multiple entries in vorbiscomments.

Monday, April 04, 2011

AudioPlayerLibrary: Playlist Support

Streaming suddenly came much more useful as I implemented m3u, xspf and pls support in the audio player library. The library treats them as alternative sources to fetch the requested stream from, not as a list of sources it needs to play. I had disabled the Internet Radio in gogglesmm, but now that http/icecast streaming actually works (aka rather usuable) I've re-enabled support for it.

Saturday, April 02, 2011

AudioPlayerLibrary Update 04/02/11

The development of my new audio player library is progressing nicely. I'm still looking for development help, but in the mean time the following things have been updated in the past couple of weeks:

  1. Added a 'http' input plugin. It's far from finished, but it already supports ice/shout-cast streams and I have been able to playback mp3 streams without problems. Lots of work still needs to happen here: http error checking, http redirects.
  2. The mpeg-audio reader has been made more robust and will now check for several valid consecutive frames to make sure it doesn't get invalid mpeg frames. On regular audio files this was never much a problem, but with streams there's a greater chance of finding garbage bytes.
  3. Started work on a 'cdda' plugin (aka audio cd reader). Basic playback for single tracks works. Most of the work remains to be done in the front end (gogglesmm), which would need to detect audio cd presence, list available tracks and possible lookup of track information on cddb.
  4. Output device configuration can now be changed from within gogglesmm. Configuration can be changed on-the-fly even while playing. Playback does automatically stop if somehow the new device fails to open. There still remains work to be here as well. Not all device settings are exposed yet (like mixer devices), but this work will slowly continually evolve when the need arrives.
  5. I added a 'wav file output' plugin. It sends the pcm output to a WAV file and is mainly for me to debug any "gaples" playback issues and allows me to easily determine whether the gap is in the stream itself or generated somehow by the soundcard.
  6. The mpegaudio reader now correctly parses lame tags and this fixes most of the gapless playback issues I had with some of the mp3 files.
So all in all, progress has been pretty good. Again I'm still hoping I could get some people interested in helping out (development). Even if you just want to test that would be fine too.

For more information please see: