[pulseaudio-tickets] [Bug 42804] raop module does not work with shairport

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=42804

--- Comment #36 from Matthias <pulseaudio at niafc.de> ---
(In reply to comment #35)
> Hi Matthias,
> 
> Thank you so much for the testing and reporting.
> 
> By looking at your patch for ALAC support, I found out that the real issue
> might not be in the ALAC encoding, but in the raw buffer handling.
> I wrote a one-line patch inspired by your patch.
> https://github.com/hfujita/pulseaudio-raop2/commit/
> 3b35e02e473873f64e2a5967f4cc55e05ae9d00a
> This fixes the "rough sound" issue in my VSX-43+Ryhthmbox, even without
> Apple's codec integration.
> I'm happy to hear any results from testing this patch.
> (However, the sound from Adobe Flash is still terrible. I suppose this is
> due to a different cause.)
> 
> Regarding ALAC licensing, I actually had a similar concern. That's why I
> haven't made my ALAC integration branch public, while I already have it
> locally.
> 
> Since I'm not a law expert in any sense, the following should not be taken
> seriously :)
> In the most optimistic way of thinking, header section in each ALAC source
> file states that the file is licensed under the Apache License, so I hope we
> can just believe it.
> However, still I'm not sure if it's okay to link Apache Licensed library
> into PulseAudio. The license file in the pulseaudio top directory says that
> the server side implementation of PA should be treated as GPL-licensed. So
> the question would be "can we link Apache Licensed library to GPL product"?
> 
> One possible workaround would be to find another encoder implementation,
> such as in libav.

Hi Hajime,

I'm not a law expert either. To be honest, I hate to dig through compatibility
descriptions of "free" software licenses instead of happily hacking a packet
buffer while listening to music over Airtunes 2 (tm) by Apple (tm) (I'll add an
extra (tm) here and there just to be sure ;)).

Just to clarify: I would be happy to release libSALAC under LGPLv3. PA would
only link to libSALAC. Library use of a LGPL library should be ok for GPL code.
libSALAC, in turn, could "library use" Apache V2.0 ALAC. But that's just my
understanding - I'm not a software lawyer (and I don't want to be one).

You mentioned a "huge latency" in your project description on github [1]. If by
"huge latency" you mean the interval of time between "playing a sound" and the
_first time_ your airplay device plays that sound, I could think of a way to
circumvent this:

1. Implement a circular packet buffer (I am about to do this).
2. Start filling the circular buffer when module_raop_sink is loaded (i. e. in
module-raop-sink.c function thread_func, whether the sink is in a "running"
state or not).
3. Send packets from the packet buffer using pa_raop_client_send_audio_packet
(as in the current implementation).
4. As a side effect, one could easily implement packet resending by using the
sequence information of the packets in the circular buffer (which in the end is
just an array).

I also noticed this delay - looking at the packet dump of a sound clip played
via airtunes it seems as if:

1. pa_sink_render_full (in module-raop-sink.c) is subsequently called after the
sink is in running state, but
2. the playback starts *after the first three timing packets are exchanged*
(after RTSP RECORD).

As a result, there is a gap (in matter of time) between the moment when
pulseaudio moves the sink from your previously selected device to the airplay
device and the point in time where the timing packet exchange is done.

If you listen to several sound clips (read: songs of a playlist) subsequently,
the interval between the player announcing a new song and start of playback is
minimal.

However, there will always be a delay between sound data relayed to PA and
playback on the remote device.

Hajime, would you mind if I forked your project github to test my packet
buffer?

Good night,

Matthias

[1]: pulseaudio-raop2 github: http://hfujita.github.io/pulseaudio-raop2/

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-bugs/attachments/20130901/d1c62582/attachment-0001.html>