'Twas brillig, and Aditya Rajgarhia at 02/06/11 08:23 did gyre and gimble: > On 05/25/2011 03:03 PM, Colin Guthrie wrote: >> If you could give more details I can advice more. >> >> Keep in mind that the Airport support is still rather rubbish in lots of >> ways (I say this as the author!) and does still need work. Timing and >> buffering in particular. > > I finally managed to get it working. I was probably not operating the > GUI applet properly. The Airport is now able to play the audio sent to > it via PA. But as you point out, there are issues with timing and > buffering which lead to extremely choppy sound that is basically unusable. > ... > You mentioned that some work is needed to tidy up the protocol. Should > it not be possible to create a PA raop sink by simply copying the > protocol implementation from raop_play? I looked at the raop_play code > and the functions implemention the actualy sending the receiving of data > are quite simple. Or are there other complications in writing the PA > sink? I'm not familiar with the details of the timing/buffering issues > you mention nor with how PA works, but is this issue something inherent > in PA, or do you think raop_play explicitly solves it? The protocol implementation is not the problem. I used raop_play extensively for my work, but it's implementation is equally rubbish in many ways, it's just that it becomes more exposed in PA. Also, the raop_play implementation is blocking, and we need a fully async implementation in PA which is what I ultimately wrote. So raop_play uses the network buffering to block when the device is full, and that's pretty much what I do in PA too at the moment, but due to the fact that PA will always render *something* (even silence) means that we get this choppiness. In reality I should time very carefully and push only what data I have to it in sensible time frames. Ideally we could push e.g. 2s into the device (assuming our latency settings are such that we support that - which for power concious apps, we will), but if something happens to change the mixed result, we need to flush the buffer on the device and resend the newly mixed audio. This is, in itself, not a problem, but controlling the timing when we do not have exactly 2s available is also needed here. Add to this that raop_play uses protocol v1 and we're currently trying to use protocol v2, there is not much use (v2 apparently has better timing capabilities but it's slow going on the reverse engineering work - not many (any) people are actively working on it right now, tho' some work has been done in the past (there is a git branch that implements it but it's not really much different to just now in terms of playback quality). If you want to get involved in the coding, it would be much appreciated. Just shout and I'll bring you up to speed! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
