| |||||||||||||
|
| |||||||||||||
My quest for a Linux audio player (Linux.com)My quest for a Linux audio player (Linux.com)Posted Apr 5, 2006 18:55 UTC (Wed) by jwb (guest, #15467)In reply to: My quest for a Linux audio player (Linux.com) by thaytan Parent article: My quest for a Linux audio player (Linux.com)
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)
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?
(Log in to post comments)
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.
|
|
||||||||||||