LOL at Spotify’s inability to make a functioning product.
For those defending “how hard it is” to code for AirPlay, it seems to be a cakewalk for EVERYONE ELSE.… Even Tidal has had it for years now.
Tidal is a much younger app. It was almost certainly made with the correct audio API out of the gate, instead of being built on older APIs. That's why I was careful to describe Spotify as a "mature app"
Thank you for this post. As usual, I learned more from the forum than from the actual article itself. I know this will probably open Pandora’s box here, but do you think Apple makes it so confusing and difficult intentionally?
Oh no, not at all.
I think a couple of typical developer bad habits are at play here. One, specific to Apple, is that their documentation is truly bad. They frequently act like developers can just read their minds or guess at shit, especially with complex low-level APIs like anything media or graphics related.
The other is, it's usually simpler and frankly more fun to say, "instead of rebuilding this old API, which was written using old patterns and old tech, we should just replace it with something simpler and modern." Specifically in the case of audio this seems to have happened three or four times.
Let me give you a specific example of what I crashed into. I wanted to write a music player similar to Poolside.fm that would consume "Shoutcast" audio streams (an open format for "internet radio"), and playback with that goofy techno y2k psychedelic screensaver f/x. I thought it would make for a kind of fun AppleTV app, retro-futurism.
Out of the three Apple audio APIs (that I'm aware of), only one can take in an audio buffer and let the developer analyze it in real time. This is necessary for audio visualizations (which I do), but also for things like voice enhancement or "smart speed" (which Overcast uses).
But that API can't read Shoutcast streams. Only one API can, and that one is like the mega dumbed down simplified API, which is good for rudimentary apps but quickly becomes useless at the point where you want to do anything interesting.
I eventually got around this problem by finding a ludicrously hacked audio API that added streaming functionality to the "analyzable" API by writing the audio stream to a file in the the file system, and making the API analyze that file as it was being written in real time. It worked, but I suspected that it would be highly error prone — like, if one were to start playing and put their phone to sleep… would that stream keep writing reliably? But I never found out because I wound up axing the whole project for unrelated reasons…
Comments
Japhey said: Oh no, not at all.
I think a couple of typical developer bad habits are at play here. One, specific to Apple, is that their documentation is truly bad. They frequently act like developers can just read their minds or guess at shit, especially with complex low-level APIs like anything media or graphics related.
The other is, it's usually simpler and frankly more fun to say, "instead of rebuilding this old API, which was written using old patterns and old tech, we should just replace it with something simpler and modern." Specifically in the case of audio this seems to have happened three or four times.
Let me give you a specific example of what I crashed into. I wanted to write a music player similar to Poolside.fm that would consume "Shoutcast" audio streams (an open format for "internet radio"), and playback with that goofy techno y2k psychedelic screensaver f/x. I thought it would make for a kind of fun AppleTV app, retro-futurism.
Out of the three Apple audio APIs (that I'm aware of), only one can take in an audio buffer and let the developer analyze it in real time. This is necessary for audio visualizations (which I do), but also for things like voice enhancement or "smart speed" (which Overcast uses).
But that API can't read Shoutcast streams. Only one API can, and that one is like the mega dumbed down simplified API, which is good for rudimentary apps but quickly becomes useless at the point where you want to do anything interesting.
I eventually got around this problem by finding a ludicrously hacked audio API that added streaming functionality to the "analyzable" API by writing the audio stream to a file in the the file system, and making the API analyze that file as it was being written in real time. It worked, but I suspected that it would be highly error prone — like, if one were to start playing and put their phone to sleep… would that stream keep writing reliably? But I never found out because I wound up axing the whole project for unrelated reasons…