If you use a general purpose media player to access your music collection, you’re missing out on a wealth of features that can improve your listening experience. That’s why we recommend a dedicated music player. Linux offers a huge range to choose from which is why we put together this roundup to help save you time. But there are always new projects coming along.
G4Music is billed as a beautiful, fast, fluent, lightweight music player.
The software is written in Vala and uses GTK4, a cross-platform widget toolkit for creating graphical user interfaces. Before we put the software that its paces, let’s briefly run over installation.
Installation
A good way of learning about Linux is to build software for yourself rather than relying on packages provided by a developer or a distribution. It takes time though and occasionally software can be difficult to build. Fortunately G4Music is very straightforward. Our Ubuntu system was missing a dependency which was installed with the command:
$ sudo apt install libadwaita-1-dev
We are now ready to clone the project’s repository with the command:
$ git clone https://gitlab.gnome.org/neithern/g4music
We use the Meson high productivity build system to build and install the software.
$ meson setup build --buildtype=release
$ meson install -C build
Installation is complete. Read on to see how the software fares in action.
Next page: Page 2 – In Operation
Pages in this article:
Page 1 – Introduction / Installation
Page 2 – In Operation
Page 3 – Memory Usage
Page 4 – Summary
Could the unanticipated high memory usage be related to the fact that the G4Music interface is GTK Version 4?
Also from a very quick look at the code, G4Music does not do any decoding or direct playing of the music but sends it off to gstreamer to do the actual decoding and playing (viz sending the audio to the appropriate audio interface pulse, pipewire or whatever). So the G4Music software appears only to be providing a GUI and file and meta-data management and the rest is done by other “Gnome” components
The vast majority of music players rely on frameworks like GStreamer for media processing. So nothing new with G4Music.
I believe GTK4 uses GL and so you end up allocating shared memory by the graphics driver. Also GTK4 uses higher memory for CSS objects and there’s more caching taking place overall than with GTK3-based programs.
Given G4Music gobbles memory as badly as Electron-based junk, I hope not all GTK4 suffer in that regard. Most apps are still using GTK3. Is there a list of GTK4 apps available? It would be interesting to see how much more bloated they are.
Sorry if you thought I was being critical of G4Music using the Gstreamer framework rather than doing the heavy audio processing work its-self. Gnome applications should of course use what is available in the GNOME ecosystem and not reinvent the wheel. The point I was trying to make was that the high memory usage was probably not coming from something in the audio processing part since that was being offloaded.
Perhaps it was unfair to suggest the problem was GTK4 — the problem may perhaps be from a memory leak in the G4Music code its-self and/or how it calls Gstreamer.
If I do a web search on “Gstreamer memory leak” there are quite a few results including from March 2021
“New GStreamer 1.18.4 bug-fix release for our stable 1.18 series. As always lots of bug fixes, stability improvements, and also some memory leak fixes.”
So what version of GStreamer was used in the test performed in the article?
Perhaps those who are testing the application could check to see at what point the high memory usage occurs — right from initialization or later on while it is building its database — and perhaps if time perhaps use a memory profiler on the process.
I don’t really follow GTK4 apps per se but I do know that Pitivi is porting to GTK 4 this summer. A great app
G4Music author here.
About the memory usage, we need more details of your running environment, if you have checked the issues of the project on gitlab, you wil not find any other issues about memory usage.
About the speed of Samba, I guess you must enabled the option “Load thumbnails for non-local files”, it do need more time to parse tags and load thumbnails, just like what Nautilus does. But after GIO cached Samba file, next loading will be faster.
Thanks anyway.
Author of this article
I got the same high memory usage results with both fresh installations of Ubuntu and Manjaro on different PCs.
Re no issues about memory usage on your gitlab, not sure why that’s important. You now know there’s an issue, and it’s easily reproducible.
I am investigating further re the slow network scanning, but again it would be better if you show progress while scanning.
it’s not easily reproducible… I tested in ubuntu 22.04 and fedora 36, with 1500 songs, about 1000 songs has embedded cover art images, it only cost less than 200MB. i guess there are some special song files cause the memory issue, or something else. It’s easy to figure out because it’s open source 🙂
How are you measuring memory usage? Hopefully not with top or a similar utility.
I use ps_mem as it’s probably the best tool for this purpose.
I measured with gnome-system-monitor and htop (by checking the amount of free memory when g4music is running and after quit).
Btw, I found a simplest GTK4 demo app would cost at least 40MB memory, and adwaita-1-demo cost at least 50MB (just launch it no more any actions).
I checked with ps_mem (still same song files):
sudo ps_mem | grep g4music
Private + Shared = RAM used Program
126.9 MiB + 25.2 MiB = 152.1 MiB g4music
How about the private and shared in your case?
The app looks good! But, regarding Samba: I’ve tried setting the app’s directory to my network music directory; I killed the app when it still was loading without any visible progress after two or three hours. Audacious, which is what I’m mostly using, seems to be one or two orders of magnitude faster there.