[pulseaudio-discuss] GSoC ideas

Mon Apr 29 03:35:54 PDT 2013

On 04/29/2013 12:18 PM, Tanu Kaskinen wrote:
> On Fri, 2013-04-26 at 16:40 +0200, David Henningsson wrote:
>> On 04/26/2013 03:37 PM, Tanu Kaskinen wrote:
>>> On Fri, 2013-04-26 at 14:54 +0200, David Henningsson wrote:
>>>> On 04/26/2013 12:48 PM, Tanu Kaskinen wrote:
>>>>> On Fri, 2013-04-26 at 05:05 +0200, Alexander Couzens wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I would like to work on pulseaudio as gsoc student this year.
>>>>>> Can you give me some feedback about my ideas, please?
>>>>>>
>>>>>> I'm working with pulse for a while and this is how I'm using it:
>>>>>> -1-
>>>>>> We have an announcements system at c-base my local hackerspace.
>>>>>> It's a multi speaker setup based on OpenWrt and Ubuntu.
>>>>>> - sender is a Ubuntu x86 system. it plays hourly time announcement +
>>>>>> samples
>>>>>> - receivers are mips32 based routers, arm systems, x86
>>>>>> This system announce every hour. Got a tts + jsonrpc interface to play
>>>>>> soundfiles.
>>>>>> The receiver disappear from time to time. (module-tunnel-sink lacks a
>>>>>> reconnect feature).
>>>>>> Also in future this setup should support playing sounds on a random
>>>>>> group of speakers.
>>>>>>
>>>>>> -2-
>>>>>> I'm using it at home
>>>>>> - remote home system: speakers connected to 1 pulseaudio server +
>>>>>> laptop as sender
>>>>>>     |- receiver announce themself via avahi/bonjour
>>>>>>     |- sender: laptop use them as sink
>>>>>> Pulseaudio should recognize your environment (how? or let the user
>>>>>> choose which environment-profile apply).
>>>>>> Different locations, different audio setup. At work you want to move
>>>>>> only mplayer/vlc/.. stream to
>>>>>> the remote sink. At home, maybe you want to move all streams over to a
>>>>>> good amplifier.
>>>>>> Playing video doesn't work reliable. Playing soundfiles works better,
>>>>>> but not perfect.
>>>>>>
>>>>>> My ideas for a gsoc application:
>>>>>> - Fix network sinks. Try to move a stream to network sink and back
>>>>>> moments later it will run into problems.
>>>>>>        e.g. mplayer just stop playing and hang. My job would be
>>>>>> additional testing and fixing upcoming bugs in pulseaudio.
>>>>>
>>>>> Making module-tunnel-sink reliable would be very welcome. Estimating the
>>>>> amount of work is hard, though, when you don't know what exactly are the
>>>>> root causes for the bugs, which makes writing the project plan hard too.
>>>>
>>>> I'd like to see a rewrite of module-tunnel-sink to use the libpulse API
>>>> instead of doing the protocol stuff directly.
>>>
>>> +1
>>
>> ...and in extension, perhaps a module-tunnel-detect that would load the
>> same amount of module-tunnel-cards, module-tunnel-sinks and
>> module-tunnel-sources as are present on the remote instance. But that is
>> just a wild idea at the moment.
>
> I agree that this would be good. We don't currently have
> module-tunnel-card, but we should. module-zeroconf-detect is already
> used for detecting remote stuff, so I don't know if we need any new
> module-tunnel-detect module.

Sure, if module-zeroconf-detect can be configured to follow a specific 
server, that would work. I haven't investigated the zeroconf stuff much.

>>>> I also think that wifi + TCP + low latency is a very hard thing to
>>>> achieve reliably. The question is if it is possible at all, and if not,
>>>> what the options are. Arun didn't seem very happy about improving RTP
>>>> support in PulseAudio.
>>>
>>> At least one option should be to not insist on low latency (IIRC the
>>> latency is now hardcoded to 150 ms). Streaming music over wifi has no
>>> need for low latency.
>>
>> 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.

>>>>>> - authentication - add password based authentication. it can be either
>>>>>> a password or a password to add your cookie to the authorized_cookies.
>>>>>> Also a request + response system would be good. Implement it as popup
>>>>>
>>>>> Authentication without encryption is very questionable security-wise.
>>>>> Perhaps it's still useful, though? I would presume that in many cases
>>>>> it's sufficient that it's not trivial for any random person to gain
>>>>> access to the server and mess with things. The current cookie-based
>>>>> authentication isn't any more secure anyway, so a password-based
>>>>> authentication would just be a more convenient way to achieve roughly
>>>>> the same level of security.
>>>>>
>>>>> We could also discuss how to add encryption support to PulseAudio.
>>>>
>>>> Somebody last year tried something popup-like, but it's not easy trying
>>>> to get that right with all Desktop Environments.
>>>>
>>>> I'm not seeing the use case for having PulseAudio handle passwords. Can
>>>> somebody enlighten me?
>>>
>>> I'd imagine it's easier (or at least more intuitive) to run "pactl
>>> set-password-for-remote-clients correcthorsebatterystaple" on a sound
>>> server machine and then type the password to a prompt when connecting
>>> the first time from each client machine, than to figure out and remember
>>> that the cookie file needs to be copied to each client machine, after
>>> the connection is failing with "Access denied".
>>
>> 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.

That would be my preferred option. If that is not possible, I think 
having an optional dependency on a crypto library would be second best, 
even if I don't like new dependencies.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic