The packet type 0x56, sequence number 0, containing 4 bytes (the first two are the sequence number of the previously requested packet) initiates a resync. Not sure what this packet is supposed to do, but it occurs after heavy requesting resending of packets. Seems to be an out of sync situation, so resyncing is not the worst idea. Signed-off-by: Gregor Fabritius <firstname.lastname@example.org>
When requesting resend of packets a lot, iOS sometimes sends a packet with type 0x56 (Reply to resend request), but with sequence number 0 and length == 4. This short length leads to memory corruption later on when processing the packet: alac_decode() expects at least 16 bytes for AES IV. Therefore the segfault. This fix ignores packets with length < 16, as seen in another implementation here: http://fossies.org/dox/mythtv-0.25.1/mythraopconnection_8cpp_source.html#l00555 Please be aware that this just fixes the segfault. The suspicious packet seems to be an information of an out of sync situation, so it may deserve further attention. Signed-off-by: Gregor Fabritius <email@example.com>
… with JACK.
We are calling out to libc's rand() function, which has significant overhead, especially since we are calling it 88200 times per second (2 channels * 44100 samples). Implement a very simple linear congruential generator in our code that is plenty good enough for dithering purposes, and small enough for the compiler to optimize and inline.
The math operations are all equivalent, but are simplified a bit for the benefit of processors with slower floating point performance. * Don't use float casts when we need to eventually convert to double precision anyway. * Use multiplication instead of division when possible.
Using the `volatile` qualifier in multithreading code is never the right answer. Mutexes should be used as was attempted with the audio buffer code. Here, we implement a new mutex for the volume and fix_volume globals, and grab a lock on it when necessary, which is for both reads and writes.
If you turned set `debug = 1` in hairtunes, you'd quickly get a mess of debug messages that showed bf_est_drift in bf_est_update() going quicky out of range toward a float NaN value (usually negative). Clearly the presence of this `out` variable in biquad_filt was meant to be used, not marked as unused.
This allows the compiler to do a much better job on this file, as it currently can't inline most of the functions because they are technically visible outside the file. Mark most functions and variables static to let the compiler work.
This makes things a bit cleaner and easier to grasp.
- when requesting a packet, do not request an already received packet - move the last-chance resend to buffer_get_frame - check more often for missing frames own checks show that some frames need to be requested up to 4 times on bad connections
The last-chance resend was sometimes fired up to 6 times (probably while receiving multiple new packets while playing the same buffer-data). The following patch corrects this: only one retry is sent out. For this to happen, I change abuf->ready to -1 ("1 retry sent out") and by changing the other comparisons of abuf->ready to != 1. Probably, this could be improved, by implementing a first check at t-30, t-20, t-10, ...
…rnings on OpenBSD Rearrange includes to fix warnings thrown on OpenBSD 4.9/i386
… buffer, given the START_FILL used for synchrony by whoever that was.
…ens file when another reader appears