Finally, the first release of 'light-play' is available on GitHub. Check out https://github.com/ErikOnBike/light-play if you are interested.
It has been a while...
My optimism had the best of me during my previous post. Unfortunately, things did not go exactly as planned. First I mistakenly thought the newer Apple TV devices would still be able to handle the old AirTunes TCP protocol. Wrong! Stupidest thing, I could have seen this much earlier, but was just ignorant of the fact. So I came from TCP, went to implementing the newer UDP approach, and ended up...nowhere... Turned out that the default m4a ALAC file encoding uses 4096 frames per packet. This results in packets larger than UDP (by default) supports. I have look around, tried different things, but in the end failed to split these large audio packets in chunks which my Airport Express would swallow (and still produce useful sounds).I'm still unsure if there is a way to split large ALAC packets in a way Airport Express can handle them. Normally, iTunes and other players will transcode the file into a format using 352 frames per packet. These audio packets fit inside a UDP packet. But my whole point was to develop a player which would not do any encoding/transcoding (including NO encryption). It should be a very light player (enough players out there doing it the full monthy). Frustrating...
Picking up the pieces
So after a period of doing nothing with light-play, I ended up changing it back to a TCP player for the good 'ol Airport Express. And there you have it. On GitHub (https://github.com/ErikOnBike/light-play) you can find it.In the long run I still might support Apple TV devices, but only with AAC files probably. As far as I know, these normally have smaller packet sizes preventing the problems I had with large ALAC packets. But I'm definitely going to look into this very carefully before adding this support. Been there, done that, not intending to do the stupid things again.
In the mean time, I will try to turn the current command line application into a server based application with a web based user interface. Stay tuned...but do not hold your breath.
Past experience is no guarantee for the future
'Past experience is no guarantee for the future', a (very) free translation of a Dutch phrase added to all TV and radio commercials regarding the savings of money based on speculation. [The fact that a savings account did result in 10% interest last year does not guarantee it will be that high (or even profitable) this year.] My past experience with programming in C dated back many many years ago. I have been doing programming and scripting ever since, so I felt it would not be a problem. It turned out to take me quite a lot more time to develop a nice solution (or in my feeling enough close to it) in a language which is so bare metal. My preferred development environment is Pharo, based on Smalltalk. Quite a different beast.The code itself now is fairly clean. Almost no need for external libraries. A makefile which could not be simpler (although this means it will not work directly on some tool chained environments as is OpenWrt). I really 'dug' the bike shed article (how appropriate for 'ErikOnBike'): http://queue.acm.org/detail.cfm?id=2349257 Happy reading...
