My quest for a Linux audio player (Linux.com) [LWN.net]

My quest for a Linux audio player (Linux.com)

Posted Apr 5, 2006 11:53 UTC (Wed) by thaytan (guest, #25908)
In reply to: My quest for a Linux audio player (Linux.com) by jwb
Parent article: My quest for a Linux audio player (Linux.com)

I'm not quite sure how to respond to your comment. I'm a GStreamer developer, so obviously I don't agree with your assessment that it's a 'fundamental design flaw' for players to use it.

Your statement that "If your program uses GStreamer, there is basically no way to report useful error messages back to the user (or even back to the program) and no way to just get a damn array of audio samples." is wrong on both points, although the first is partly true.

1) Producing useful error messages in a generic streaming framework is hard. The big problem currently is that many GStreamer plugins report generic errors where they should report specific ones. We're improving that as we go, and they're getting better. In 0.10 there is a clear mechanism for producing error messages to the application, categorised into one of a bunch of defined error classes and providing a mechanism for supplying translations to different languages.

2) You mentioned trying to hack your MusicIP fingerprinting into Rhythmbox. I assume that means during the song import? You can do this in a couple of ways:
a) Write a GStreamer element based on the BaseTransform base class and drop it into the pipeline somewhere. You'll pretty quickly have a GStreamer element that can be reused in every existing GStreamer based player with the addition of maybe 10 lines of code to each.
b) Look at the part of the metadata importer that connects fakesink to the pipeline and either add a buffer-probe to the input of fakesink or connect to the handoff signal. Either one will provide you with a way to have GStreamer call a callback whenever there's a buffer of audio data to be processed.

a) has a longer lead time, but is more reusable. b) will get you there quicker.

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/... shows you sample code of how to do b)

http://webcvs.freedesktop.org/gstreamer/gst-plugins-good/... is a good example of a filter element that analyses the audio passing through and sends custom messages to the application reporting the results.

In case you didn't already find it last week when you were having trouble, you are welcome to jump on the #gstreamer channel of the freenode.net IRC server and ask before deciding the mechanism isn't there.

(Log in to post comments)

My quest for a Linux audio player (Linux.com)

Posted Apr 5, 2006 18:55 UTC (Wed) by jwb (guest, #15467) [Link]

Thanks for your thoughtful reply. I'm not really planning to argue about it, because, really, what's the point? It's not like convincing you to stop developing GStreamer would be a positive accomplishment, and as a developer you have presumably already decided that the design of GStreamer is to your liking. And there is clearly a community of GStreamer users who think that GStreamer is also to their liking.

So I'll just reply to say that GStreamer programming requires a certain way of thinking that doesn't really agree with my brain. I find this code easy to understand and modify:

vf = ogg.vorbis.VorbisFile(name)
while 1:
(buff, bytes, bit) = vf.read(4096)

if bytes == 0:
break

musicip.consume(buff, bytes)

Whereas I find that when I need to work with GStreamer I quickly have lots and lots of code dedicated to factories, pads, signals, callbacks and lots of other things that are identified by strings. Even in python this adds up to many lines of code.

Here's an example of the error handling stuff I'm talking about. Suppose you build your pipe but then you get an error while settings the state to STATE_PLAYING. How can my program intelligently deal with any of the dozens of errors that could have caused the state change failure?

My quest for a Linux audio player (Linux.com)

Posted Apr 6, 2006 15:32 UTC (Thu) by thomasvs (guest, #36955) [Link]

Well, how would your example application deal with any of the errors that could happen when trying to read from a file ?

Most applications special-case a few of the errno values, and then print a generic string with strerror()

Are these generic strings very good ? No, because they are generic - they don't have enough contextual information about what the application was doing when it triggered these problems.

In your example, using Python, you would get a confusing traceback because of a raised exception - for example, IOError if it couldn't find the file.

You have to accept that handling errors correctly is hard intrinsically. The application needs to combine information about the lower-level error *and* its execution context to interpret what has gone wrong and show a useful error for it.

Also, remember that your simplified example is not an application on the scale of totem or rhythmbox - there is yet more code involved to show a decent dialog with this information.

My quest for a Linux audio player (Linux.com)

Posted Apr 6, 2006 15:42 UTC (Thu) by zaheer (guest, #36979) [Link]

Now change your code so that it handles other formats autodetecting on the way, say flac or mp3 or wav

Now also add a feature to take it from an icecast stream rather than a file, or from another machine over ssh/sftp.

Guess what, this code now becomes a lot harder and you start implementing a mini framework.

My quest for a Linux audio player (Linux.com)

Posted Apr 6, 2006 19:38 UTC (Thu) by lysse (guest, #3190) [Link]

Gstreamer has to do that, because it has to be coded for any eventuality and be usable by anyone. However, if you already know that you don't require anything other than the one format, or the one source of music, there's no need for that additional complexity.

Using off-the-shelf software is a trade-off; it states that your time is worth more than your machine's memory, and that writing code is Always Hard. Sometimes that's not the case - sometimes it's quicker to just get out the text editor and write exactly the code you need than it is to figure out the all-singing, all-dancing framework / library / whatever. For a proficient coder, "sometimes" might become "more often than not".

To tie it back to an earlier discussion, bloat is the price of not writing your own need-specific code.