Hi R?mi, hi Hajime, >>> 1) it would consume 100% of the CPU time >> No, it won't. poll() will *not* return immediately. > > Oh you're right. For some reason I misunderstood that poll(..., -1) > meant "no wait, return immediately" but actually it was "no timeout, > wait forever". >... >>> 2) it would block the message loop (I'm not sure about the real >>> implication of this, though) >> >> But yes. I understand that either way poll() would block the message loop. I re-wrote my patch so that packets are discarded when blocking occurs (as was my first thought, and Hajime's suggestion as well). You can find it in my fork of Hajime's repository on github [1] and attached below. Greetings, Matthias [1]: https://github.com/emwe/pulseaudio-raop2/commit/d9b9c822ef1d0b2b55601b0d2958190644e574fc diff --git a/src/modules/raop/raop_client.c b/src/modules/raop/raop_client.c index f699fd8..eb4a582 100644 --- a/src/modules/raop/raop_client.c +++ b/src/modules/raop/raop_client.c @@ -560,7 +560,10 @@ static ssize_t udp_send_audio_packet(pa_raop_client *c, bool retrans, uint8_t *b int fd = retrans ? c->udp_control_fd : c->udp_stream_fd; length = pa_write(fd, buffer, size, NULL); - + if ((length == -1) && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) { + pa_log_debug("Discarding audio packet %d (blocking)", c->seq); + length = size; + } return length; }
