When I wrote out my initial plan for the sound recorder, I decided to start with the backend. I haven't used GStreamer before. I generally prefer to put the steepest part of the learning curve first, since I find that the bast way to learn any coding skill is to spend some time drowning in deep water (well... or even shallow water. I'm pretty sure I could manage the drowning at first part no matter what coding skill I'm learning).
So I have indeed been coding the backend functions. I've been reading a lot of code, and monkey-copying a little too much. So far I have some code that I stole from:
Transmageddon - it has some handy methods for defining encoding container types, encoding audio profiles, and file extensions.
Sound Juicer - I spent some time the other day stealing error handling from Sound Juicer. It puts a bus on encodebin and listens for errors missing plugin errors emitted by the encodebin. Today my mentor told me that I'm supposed to be listening for errors on the pipeline's bus. You wouldn't think that would be difficult to understand, but I ended up getting confused. When I looked at documentation for adding a bus to a pipeline, there were two ways that buses were handled: either they were connected using add_watch() or by popping messages of the bus and handling them if they are the correct type. Sebastian told me to use add_watch, but I wasn't able to return any errors because I asked the bus to listen before I set the pipeline to Gst.State.PLAYING.
GNOME Shell - I stole an interesting while loop from GNOME Shell a few days ago and I've been trying to work out exactly how to handle callbacks in it. I'm using it to gather metadata about the files in the Recordings directory so I can populate a listview. I'm interested in having an asynchronous callback that passes the data to the code that populates the listview after it's returned data about 50 files, and then continues gathering data.
So in general I'm having a lot of fun trying to understand and learn from the code base. I never learn as quickly or as well as I would like, and I tend to destroy more code than I create, but there you have it: my weekly update :)
Awesome progress Meg, sounds like you're having fun! ^^
ReplyDeleteFor populating your list, use GstDiscoverer, for example:
ReplyDeletehttps://git.gnome.org/browse/totem/tree/src/totem-properties-view.c#n320
and to start the discovery:
https://git.gnome.org/browse/totem/tree/src/totem-properties-view.c#n359
For a simple player with error handling, see:
https://git.gnome.org/browse/totem/tree/src/totem-audio-preview.c
I wouldn't worry too much about missing plugins handling, presumably you'll save and load the recordings in a free format, so that the basic GStreamer installation would have the necessary plugins.
Thanks for the pointers, Bastien! I suppose GstDiscoverer is a better solution, although it was kind of fun to read thru GNOME Shell code :)
DeleteCool stuff!
ReplyDeleteI tried compiling the github-branch on https://github.com/MegFord/gnome-sound-recorder/tree/github by cloning into my jhbuild checkout dir and running "jhbuild make". It failed with this message:
configure.ac:19: error: required file 'data/gnome-sound-recorder.desktop.in.in' not found
libgd/Makefile.am: installing './depcomp'
configure.ac:19: error: required file 'src/gnome-sound-recorder.in' not found
Did you forget to push some files or did I do something wrong?
Nope, I forgot to add the files after I re-named them, thanks for the catch :)
DeleteI pushed them now. Giovanni's gtk-js-app originally required you to add branches['gjs']='wip/package' to your jhbuildrc and rebuild gjs with buildone -fa. Not sure if the branch has been merged, you'd have to ping him -- or check the git :)