Hi Anton, hi Hajime,
>
> I also se some:
> D: [lt-pulseaudio] rtsp_client.c: Sending command: RECORD
> E: [raop-sink] module-raop-sink.c: Failed to send UDP packet: Resource temporarily unavailable
I also encountered this issue with shairport (which dumps core instantly) and my Minx Air and am currently developing a patch to remedy this.
To put it short, that's because we're sending udp packets on a non-blocking socket, and the socket is blocking (in my case, that is because the network send buffers are full).
The error message "Resource temporarily unavailable" corresponds to error code EAGAIN (or EWOULDBLOCK).
Now for the long version (and for you, Hajime):
I suspect the reason in commit 108714446a96c4ac601d331de55f05cb5f8388bc ("raop: Refactor UDP packet send path") which among others replaces pa_loop_write() in udp_send_audio_packet() with pa_write() in raop_client.c.
That's not the reason for the failed send; it just (correctly) triggers the error handling in module-raop-sink.c, resulting in the message above.
In the original code, send_audio_packet() used to pa_loop_write() bytes of the audio packet to the udp streaming port. If pa_loop_write() failed (by returning -1), send_audio_packet() would return 1, else 0. However, module_raop_sink.c still checks for a return value of '-1', which is in the current branch is (correctly) handed back by pa_write() to udp_send_audio_packet() up to module_raop_sink.c.
The easiest way to handle EAGAIN of non-blocking buffers would be to simply drop the packet and let the resend buffer handle re-sending. However, I just try to have a look at the reason _why_ EAGAIN is returned by pa_write() in this case - or, better put, why the send buffers are full at all.
I just saw that pa_write() has special handling for non-blocking sockets emitting WSAEWOULDBLOCK under Windows, maybe we can adapt that in this case.
Will write back if I found out more.
Greetings,
Matthias
