Hi Matthias,
Thank you for investigation.
I'm curious why EAGAIN actually happens. Are we sending packets faster
than the network link (I doubt it)?
Anyway, I also saw it in my environment while the probability is quite low.
As you wrote, my suggestion is to just ignore & drop the packet,
assuming that the number of packets encountering EAGAIN is quite small.
Thanks,
Hajime
Matthias Wabersich wrote:
>
> 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
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
