Summary
G4Music is an attractive music player in many respects. Its GUI is functional if somewhat basic, and the program is pretty stable. The fact that G4Music has good gapless(1) playback support, embedded album art support, as well as MPRIS support are definite pluses. It’s missing a few features which we would have liked such as playlist support, lyrics, and native desktop notifications. If you like plugins, you’ll also be disappointed as the software is missing extensibility.
The software is extremely fast scanning a music collection although loading a large collection over a Samba share was interminably slow. It appears the program hangs because there’s no realtime scanning progress displayed, but eventually the software loads the collection. Annoyingly you can’t start listening to music until the whole process is complete.
We were disappointed with G4Music’s memory usage. It definitely doesn’t have a small memory footprint as billed. Hopefully the developer can address this issue.
Overall, G4Music is a competent music player if your looking for a simple to use music player. If the developer can reduce the memory footprint, add a sprinkling of extra features, we would heartily recommend this music player. For now, it’s a work-in-progress.
(1) Gapless playback is the uninterrupted playback of consecutive audio tracks, such that relative time distances in the original audio source are preserved over track boundaries on playback. It’s essential if you listen to classical, electronic music, concept albums, and progressive rock.
Website: gitlab.gnome.org/neithern/g4music
Support:
Developer: Nanling Zheng
License: GNU General Public License v3.0
G4Music is written in Vala. Learn Vala with our recommended free books and free tutorials.
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.