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 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.
- Implementing profiles for different environments. The user can
define a profile for home, work, [...]. Main sink, group of sink
(combine sinks)
I can imagine that there are many users who would benefit from this. We
plan to have major changes to how routing (and other) policy is handled,
and it's not clear to me yet what the end result will look like. Our
general goal is to make things Just Work with minimal (preferably zero)
user configuration, but I'd imagine that it wouldn't be a problem to
have the possibility to have support also for user-configurable sets of
static policy rules (which is what profiles are).
Profiles, in PulseAudio today, is a concept related to the number of
channels a sink/source currently has. If we continue to call this
"profiles", it's guaranteed to be confusion.
Good point. We could call the things discussed here "configuration
presets" (too wide scope?) or "routing presets" (too narrow scope?) or
"policy presets" (too obscure term?).
- Simplified way for scripting pulseaudio and doing basic event
handling. Normal (power) user should script their soundsystem.
I believe there's general agreement that we want Lua scripting in
PulseAudio. I think this would be a very good GSoC project.
Eh? I've never heard of adding Lua scripting before,
Hmm, it was discussed briefly in PulseConf (at downstairs, before the
event officially started). My recollection is that Janos brought up the
topic, and me and Arun ended up agreeing that it would be a good thing
to have (for example, it makes it easier for users to implement whatever
strange policies they may want to have). You apparently weren't present,
I'm not sure about Colin.
For what it's worth, I remember Lua scripting is also something that
Lennart wanted to do for a long time, but never got around to it.
and I'm very much
against adding yet another dependency to PulseAudio without a very very
VERY good reason.
That said; it looks like liblua 5.1 is part of ubuntu-desktop already,
so that particular dependency would not cause too much trouble in
desktop scenarios much, but it would still bloat embedded scenarios,
which is bad enough.
So make it an optional feature, problem solved?
Well, it depends. If we start to use Lua ourselves, and ship Lua scripts
as our recommended way to do something, it's optional in theory but not
in practice.
Or, to look at this from another angle - what's wrong with shell
scripting? What things are there that you can't do with shell scripting
today that Lua would solve?
Executing code synchronously in a hook is one thing that will never be
available via shell scripting.
That said, Alexander's original idea was "simplified way for scripting
pulseaudio and doing basic event handling". That doesn't necessarily
mean server-side scripting. I don't think we currently provide very nice
tools for client-side scripting either, so e.g. a Python library would
be one possible project.
It seems to me that in either case (client-side or server-side), this
should be provided as some type of C API, rather than messing with a
different language. Then people can implement their stuff in what
language they want (since C bindings are available for most common
languages).
- 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...
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
[1]
http://stackoverflow.com/questions/12691017/wifi-lag-spikes-after-quiet-period
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
