In Operation
Here’s an image of G4Music in action.
The music player supports a good range of audio formats including our recommended format FLAC. There’s support for remote protocols including Samba which is useful if your music collection is stored on your LAN or in the cloud.
Let’s take a brief look at the interface. In the top left hand corner is a 3 line icon. This brings up preferences which lets you choose a dark theme, define the music folder, and whether to load thumbnails for non-local files. By default, the audio peak level is displayed, and gapless playback is enabled.
There’s also the option to use ReplayGain to normalize volume, and use Pipewire audio sink, the latter is an experimental feature.
Also at the top left are icons to let you sort by album/artist/title/shuffle playback, together with full-text search. The rest of the interface shows the music tracks, album art, together with the usual playback buttons and volume slider.
Next page: Page 3 – Memory Usage
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.