Ah ok, my bad, thanks for the explanation.
>No, the existing code is correct. Incoming "'audio/L16" RTP data is
>(by definition) in network (big-endian) byte order. It's up to
>whatever downstream object uses this data to decide whether or not it
>wants to byte-swap it. (Note that your patch
No, the existing code is correct. Incoming "'audio/L16" RTP data is
(by definition) in network (big-endian) byte order. It's up to
whatever downstream object uses this data to decide whether or not it
wants to byte-swap it. (Note that your patch would not work on
big-endian architectures, be
Hi Ross,
I'm not sure if there's any reason against this patch,
but since 16-bit PCM audio is always transferred in network byte order,
shouldn't the byte order be swapped again on the client side before the sink
receives the data?
Or is there any case where this isn't true?
On the other hand,
