<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - raop module does not work with shairport" href="https://bugs.freedesktop.org/show_bug.cgi?id=42804#c51">Comment # 51</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - raop module does not work with shairport" href="https://bugs.freedesktop.org/show_bug.cgi?id=42804">bug 42804</a> from <a class="email" href="mailto:pulseaudio@niafc.de" title="Matthias <pulseaudio@niafc.de>"> Matthias</a> <pre>(In reply to <a href="show_bug.cgi?id=42804#c50">comment #50</a>) Hi Hajime, > > A possible explanation could be that my remote device accepts re-sent audio packets at the streaming port > (regardless of payload type(!)) if the sequence number matches the one requested. > > This would make sense. In principle there is no order guarantee for UDP/IP, > so the device should expect reordered/delayed packet. > So if the device ignores the payload type field, the behavior would be the > same as for natural reordered packet. That's right - though I think the receiver should not simply ignore the payload type. But that's not for me to decide. > BTW, by reading raop_packet_buffer.c, I realized that pb_get_packet() did > not work (i.e. did not copy the data to the given user buffer). > > packet_data = packet->packet; > This is just manipulating the pointer, not touching the data referenced by > the pointer. > > FYI, in C, it should have been either: > for (i = 0; i < len; i++) > packet_data[i] = packet->packet[i]; > or > memcpy(packet_data, packet->packet, len); I think that adds me to the mass of people who don't get C pointer semantics right :). Thank you for clarification. > As a result, even the retransmission packet was accepted by the device, we > could not expect to hear a meaningful sound from it. > Probably this is the reason that I experienced sound glitch on > retransmission when I tried your patch first. Makes sense to me - maybe in my real-world capture case I just overheard the glitch... it was late last night. > If you don't mind, I'll take a look and rewrite the code. (At the same time > I'll adapt the code to the latest raop2-for-merge branch.) Feel free to do so. Greetings, Matthias</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>