[pulseaudio-discuss] GSoC ideas

[Tanu Kaskinen]

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.