Crashes when getting audio from Apple Tv about airfloat HOT 12 OPEN

UPDATE: Seems I was somewhat wrong above. libairfloat does appear to tolerate changes to frames_per_packet mid session, so long as it's not built in Debug mode. Building with the Release config avoids the assert related crashing when attempting to stream from an Apple TV.

And, for those unfamiliar with xcode, here's how to disable Debug for this project: you'll want to edit the Run scheme to use the Release build configuration. It defaults to Debug, which is causing our problems. To do that, go to the Product/Scheme/Edit Scheme... menu. Then, in the sheet that pops up, select the Run menu on the left, and on the right change the Build Configuration from Debug to Release. Then close the sheet, go to the Product menu and select the Clean menu item, and then you're ready to press the "play" button again to build and install on your attached iOS device.

from airfloat.

I have compiled AirFloat and have it running well on my iPhone 6 running 9.02. Airplaying music from my computer to iPhone works fine, Airplaying music from Apple TV to iPhone works fine too (EDIT- now it is crashing on music too.)

But Airplaying audio from movies from Apple TV crashes AirFloat. Typically the cover art for the movie will briefly appear on the AirFloat screen, then the app crashes. Once in a while, the audio actually works. I've tried different ways of starting the audio on my iPhone to see if there's some magic recipe (first pause the movie, waiting a few seconds after selecting AirFloat before restarting movie, etc.) but nothing works.

Any ideas as to why this happens?

This is actually my main desired usage for AirFloat- watch movies while listening to audio through headphones. I used to have an app on my Kindle (AirReceiver) that doesn't crash when doing this, so theoretically it should work. I have side loaded the app to my iPhone via Xcode, have not tried jailbreaking and installing from Cydia- I assume it's the same code and same app.

Thanks!!

from airfloat.

Another crashy data point with a compiled version of the app and Apple TV (v3). I could stream to the app from iTunes, but streaming from the appletv crashed the app instantly.

from airfloat.

I ran the AirFloat on the iPhone 6s Plus while tethered to Xcode to get some debugging info. Here's the error that occurs when my Apple TV 3 attempts to use AirFloat as an AirPlay output device:

Assertion failed: (current_packet->sample_time == c_sample_time), function _audio_queue_debug_check_queue_consistancy, file /Users/zachfine/Downloads/AirFloat/libairfloat/libairfloat/audioqueue.c, line 226.

(lldb)

It stops on this line in libairfloat/Audio/audioqueue.c:

            assert(current_packet->sample_time == c_sample_time /* Package has bad sample time */);

And just below that Xcode says:

RTP UDP Socket - Receive Loop (14): signal SIGABRT

I've also attached a screenshot of the Xcode window and debugger which shows more information.

I'm also attaching a more maximized debugger window, in case there's any useful information visible on it. I just don't understand AirPlay well enough to spot the problem myself, but am hopeful that there's something obvious in this data. I'm happy to gather whatever information would be helpful to figure out this problem.

Configuration info:
My AppleTV is running OS 7.2 (7512)
connecting to AirFloat running on an
iPhone 6S Plus running iOS 9.0.2

The iPhone is on wifi, the ATV is connected via ethernet.

from airfloat.

There must just be something in the Airplay headers sent by the apple tv that's slightly different than what it's expecting, and the necessary info to figure it out is either viewable there in the debugger or there's gotta be a way to dump the stream the app's received and have a look at it.

from airfloat.

I actually still use AirFloat on my iPhone 6 with iOS 9.1 with my AppleTV (3rd gen) with the latest software, also on Ethernet.

Getting it to working requires patience. For me, it fails to start maybe 80% of the time, and when it fails, it's always the result of a crash like you observed. Anecdotally, it seems more likely to work when following some convoluted steps, but it might be my imagination, because it's easy to find misleading correlations when something crashes with this sort of frequency.

When AirFloat crashes, I:

1. I immediately open the app switcher, and kill AirFloat before I try again, so that it starts up clean.
2. I let the video play before I go to the ATV option screen in order to select desired the Airplay speakers. It seems to work more often when starting from a playing video rather than a paused one. I can't imagine why.
3. I relaunch Airfloat only after I'm already on the ATV screen to select the Airplay speakers.

Those are my steps to achieve a 20% success rate.

The fact that it doesn't always fail is interesting, and that it only fails at startup, and not in the middle of the stream.

It looks like it's walking the queue to sanity check it, and when comparing the time codes with (the prior packet's time code + the duration of that packet's payload), it finds a mismatch. Just browsing the source, there doesn't appear to be an obvious reason why. It looks like the sample time comes directly from the UDP audio packet payload's first 32 bits, sent from the AppleTV, so either the ATV sent messed up data, or the queue got screwed up somehow, either by being out of order, or having missing or dupe packets? But, elsewhere in the code, those queue management conditions seem to be handled, so I don't know. Perhaps they're failing somehow? Or maybe it really is bad data from the ATV that has to be handled differently.

Since this section of code is just a sanity check when running with DEBUG=1, It would be interesting to see if the app still crashed if DEBUG was set to 0. It probably will, but it might just have an audio blip? I don't know. It would be nice to have one of the original developers take a look.

It might be illuminating to output the current packet values and the expected values inside that loop to see where things go awry, and how far the expected values are off.

(I might test this after the holiday, as I'll want to get an HDTV to sit near my computer, so I don't have to run around the house. :)

Since the actual issue seems to be in libairfloat, which has it's own project, it might be worthwhile posting an issue over there? I'm sure it's the same contributors in both projects, though.

Also, instead of worrying about this, you could get an Apple TV 4th Gen, which has built in support for bluetooth headphones, and avoid the need for an airplay to iPhone work-around.

from airfloat.

I took another look, and it seems the problem is caused by the AppleTV changing the number of frames per packet mid stream. It looks like libairfloat doesn't support that. That's the main problem. It seems that every once in a while the AppleTV just happens not to change the frame size, and then everything works, but most of the time, it alters it, and libairfloat isn't prepared to handle that.

While not of primary importance, this issue also seems to reveal an error in libairfloats semantic interpretation of the packet's time -- the code (at least the debug code) assumes it's a start time, but it appears to actually be an end time. The assert fails because c_sample_time is post accumulating frames, where as it should have been initialized to 0, and pre-accumulate them. That is to say, inside the loop, it's incrementing the values after the assert, while it should increment before hand. We can tell that because the sample_time in the packet reacts to the number of frames in that same packet, rather than the prior packet. And we only notice that because the ATV changed the number of frames per packet in the middle of the queue.

I did notice that frames per packet changes between sessions, so it's already dynamic, but not within a session. I've personally never done any audio programming, or much C or iOS programming, and all I know about AirPlay is what I've read in this source code tonight, so it's hard for me to say how difficult this in-session-dynamic-frames-per-packet feature would be to implement. I don't know whether the the audio device would need to be closed and reopened to accomodate the change, but I bet @trenskow probably knows many of the answers off the top of his head.

from airfloat.

Thank you!! I will give it a try tonight. Funny that you listed all those steps above, I was also trying to figure out the 'magic steps' that would lead to occasional success. But no matter what I tried, the success rate was never very high so I gave up (I ended up buying a older Airport Express A1264 just to use as an Airplay client with my Apple TV.)

from airfloat.

Success!!! I just played a trailer with Airplay to my iPhone with no problems. I only tried once, but will update if I run into any problems.

from airfloat.

Great! There are still some other crashes, when pausing/resuming or switching videos, but it's a big improvement.

from airfloat.

Now that I've got it compiled in release mode, it's fantastic.

There are two minor issues:

• It does have a tendency to disconnect if I pause playback for a bathroom break, or otherwise interrupt playback for a few minutes. I don't know if that's an unavoidable break in the connection from the AppleTV side of things or whether it's something AirFloat could change.

• The preferences are not very sticky, maybe they only last while the app is running but are reset to their defaults when it's next launched?

Other than that, it's wonderful to have wireless uncompressed audio running from the Apple TV to my phone to my headphones. Apple really should include this functionality in the iOS Remote.app, but until then…

from airfloat.

When compiling in Release scheme I'm getting link errors for 5 of the decoder_alac_* functions in Xcode 7.3.1. Very strange since those are clearly present in the libairfloat project. I tried also re-compiling libairfloat in release mode but no change. Anyone else see this?

Note: the debug scheme compiles & runs on my phone yet crashes immediately when streaming from an AppleTV :(

from airfloat.