[pulseaudio-discuss] An raop2 support

[Hajime Fujita]

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