-
-
Notifications
You must be signed in to change notification settings - Fork 576
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bad audio packet detected with HTC Connect #338
Comments
Hi Jörg Krause. This is intriguing. Does any sound come from Shairport Sync? |
Only some chunks. |
I enhanced the debug output of https://github.com/mikebrady/shairport-sync/blob/master/player.c#L249 to print the value of the variable
|
I added some debug outputs to the alac decoder and compared the outputs between HTC Connect and iOS 9.3. The main difference are the parameter
Additionally, I added a debug message to see if a 'good' audio packet was detected [](compared to a ['bad' audio packet]%28https://github.com/mikebrady/shairport-sync/blob/master/player.c#L401%29). Furhtermore, I logged the output samples in the ALAC decoder. This is the output for the HTC Connect:
|
I can confirm that HTC Connect works fine with an Apple TV. |
Hi Jörg-Krause. Thanks for all this detective work. I am very reluctant to start using the Apple decoder at this time, as the way I went about including it is a dirty rotten hack. It'll take me a while to straighten it out for public consumption. In any case, it would still suffer from the problem of that all packets are assumed to be the same length – 352 frames. This assumption is built in to Shairport Sync, and is not a property of the existing decoder, made by David Hammerton. What I will try to do is modify Shairport Sync to work when the number of frames is less than 352. Then we can see if David Hammerton's decoder continues to work. If not, then we might be forced to use the Apple decoder. |
Fair enough! Many thanks! |
Thanks. Part of my delay in responding was [unsuccessfully] trying to get hold of a HTC phone. Anyway, I'll keep trying. |
I've just pushed a new branch called |
Awesome! Yeah, it works! Many thanks for implementing this without the ability to test! |
Thanks to you for such precise information – it would not have been possible to attempt this otherwise. I made quite a few changes, so it really needs a lot of testing. I'll move it to the development branch in the next few days. |
Hi Jörg-Krause. Would you have any statistics output from the HTC? Most of the Android implementations of AirPlay players I've seen so far have wide timing variations and I was wondering if an "official" one would be better... |
Sure!
|
Thanks. It looks like the timing variations are just as large – it's probably worth making the |
I did set the drift to 882. |
Wow, then it's really all over the place! |
Sorry, but what does it mean? |
Sorry – it's English idiom -- see http://english.stackexchange.com/a/310124 for example. In this situation it means that the HTC's timing is very imprecise. |
I see! I thought as much, but was not sure. Many thanks for the explanation. |
HTC supports AirPlay on some Android devices, e.g. the HTC 10. To use AirPlay on these devices you need to install the updated HTC Connect app: http://www.cnet.com/how-to/how-to-use-apple-airplay-on-the-htc-10/. HTC has an officially license to use the protocol natively from Apple: http://9to5mac.com/2016/04/12/htc-10-first-android-device-native-airplay-streaming/.
Using HTC Connect with shairport-sync results in a lot of these messages:
This is the log until the first occurence of the error:
The text was updated successfully, but these errors were encountered: