Looking at the code I don't think that increasing the size of that buffer was ever going to change anything. I'm not a C coder myself, but looking at the code I think increasing that buffer size would only ever have helped deal with single large packets (which should never occur anyway, as SqueezeCenter is supposed to limit them to 1400 bytes).

As I see it read_packet() is called every time the UDP socket is polled and the following happens:

- xcalloc is called to allocate a chunk of memory to match the buffer size
- recvfrom() is called to fill the buffer from the UDP socket
- we inspect the first byte of the buffer to determine the packet's type
- if it is an MP3 data packet we send it off to receive_mpeg_data() for processing
- if it is not an MP3 packet we do other stuff with it

And that is it. Given that SqueezeCenter is already set to limit each UDP packet to 1400 bytes upping the buffer size. Unless...

...I don't know much about C/Unix socket stuff. Is expected to return the data for a single UDP packet or all the data that is waiting on the socket ?


If recvfrom() can return more than one packet then the code in read_packet() is very broken. At worst if two MP3 packet were waiting we would send an extra byte of duff data (the identifying byte on the front of the second packet) to the MP3 decoder. At worst MP3 packets would get missed if there was one queued up behind another packet type.

Also, the code never appears to free up the memory, surely it should be calling xfree() or something ?

Finally, the buffer is allocated within the read_packet function, which is called for each and every packet. Would it not be better to allocate the buffer in main() and pass the pointer through to read_packet() ?

No doubt I've got the wrong end of the stick though, probably best if I stick to C#

Edit: my research suggests that recvfrom() only returns one packet, so I think that side of it is a non-issue. I still think that raising the buffer size was still a non-starter though