On Mon, 2013-04-29 at 12:35 +0200, David Henningsson wrote: > On 04/29/2013 12:18 PM, Tanu Kaskinen wrote: > > On Fri, 2013-04-26 at 16:40 +0200, David Henningsson wrote: > >> I tried to google a bit for how long latency Wifi really has, and at > >> least this [1] link points to a second or two not being too unusual. > >> > >> And seconds of latency is an annoyance even over Wifi. > > > > Sure, but I think it would still be in many cases better than occasional > > drop-outs. To me TCP seems better than UDP for raw PCM data in pretty > > much all cases, except when there is a hard requirement for an upper > > limit in latency. > > I admit that I don't know much about network latency, but my impression > is that we have different people who every now and then drop into our > IRC channel asking why there are several seconds of latency for a simple > network connection, and they are not happy with it. Hmm, for some reason my impression is that the most common complaint is that the audio is choppy if it works at all. I don't remember much complaints about latency, except maybe someone has at some point complained that when the audio starts to work, the latency is something really crazy, tens of seconds (but my memory is really fuzzy about that). > >> Right. Then it sounds like an encrypted connection would make more > >> sense, e g an ssh tunnel that would already cover for both passwords, > >> keys and what not. However, if that means an additional ssh library to > >> depend on... > > > > Can you clarify your position? It sounds like you're arguing for two > > things: > > > > * We should not implement password support before encryption support, > > because they may not be completely orthogonal. For example, if we choose > > SSH tunnels as the encryption solution, we may get password > > authentication for free (I have doubts about that, but I don't know the > > capabilities of SSH well enough to argue). > > > > * We should never implement encryption, because that introduces a > > dependency on a crypto library (implementing crypto ourselves is out of > > question, I think we can agree that much). > > > > Those two statements are in conflict: if we will never implement > > encryption, it doesn't make sense to argue that password authentication > > should wait for encryption support. I probably misunderstood you. > > Well; having given this a second or two of thought, I think the best > option would be if we had existing support outside PulseAudio. SSH > tunnels can be made by ssh without explicit support within PulseAudio. > It is also something long wanted to have ssh forwarding of the > PulseAudio protocol, just like the X protocol. Can that work with auto-detected remote servers in a user-friendly way? Let's say that you connect to a new network (imagine Alexander's hackerspace network) with a remote server advertising PulseAudio capability. It would be nice if pavucontrol showed that there's a remote server available, but it requires a password before its services can be used. -- Tanu --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
