Re: [pulseaudio-discuss] GSoC ideas
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. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] GSoC ideas
On 04/27/2013 05:12 AM, Arun Raghavan wrote: On Fri, 2013-04-26 at 16:40 +0200, David Henningsson wrote: [...] - 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). Practically speaking, this does not work. You end up with a large set of poorly supported bindings, instead of one really well-support language (see: GNOME). Well, that really well-supported language would be C, if that's what the API was in. Also, we could make a C header that was clean enough for most of the auto-binding-generator tools to be able to process, if that helps. I think having an embedded scripting language makes a lot of sense (Lua is a popular choice for embedded interpreters because it's light-weight). We repeatedly run into embedded cases where people need to write their custom policy modules. Having a mechanism to script this instead of writing C would make things easier. I don't know Lua much, but for me it would definitely be harder, not easier, because 1) I would have to learn a new language. And while learning the basics of a language is not that hard, finding and understanding all its quirks in its implementations is really time consuming (and that's what you need in order to track down bugs). 2) I would have one more dependency on PulseAudio, that needs to be maintained, a potential source of bugs, version transitions, etc. 3) There is always an efficiency cost when switching between languages, in this case, jumping back and forth between the Lua interpreter and the PulseAudio compiled code. 4) If I write a module, I have access to the core and all sub-objects. We would typically choose some subset if we were to write some lua bindings. (If we were to do a stable C API for modules, that would probably also be some subset, so this argument is more a comparison to the current situation.) -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] GSoC ideas
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"
Re: [pulseaudio-discuss] GSoC ideas
On Fri, 2013-04-26 at 16:40 +0200, Alexander Couzens wrote: > On Fri, 26 Apr 2013 14:54:19 +0200 > David Henningsson wrote: > > > On 04/26/2013 12:48 PM, Tanu Kaskinen wrote: > > > > Making module-tunnel-sink reliable would be very welcome. > > I'd like to see a rewrite of module-tunnel-sink to use the libpulse API > > instead of doing the protocol stuff directly. > A rewrite could work much better for a project plan? I think this would be a good project. -- 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. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] GSoC ideas
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. > >> 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. > - 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 correcth
Re: [pulseaudio-discuss] GSoC ideas
On Fri, 2013-04-26 at 16:40 +0200, David Henningsson wrote: [...] > - 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). Practically speaking, this does not work. You end up with a large set of poorly supported bindings, instead of one really well-support language (see: GNOME). I think having an embedded scripting language makes a lot of sense (Lua is a popular choice for embedded interpreters because it's light-weight). We repeatedly run into embedded cases where people need to write their custom policy modules. Having a mechanism to script this instead of writing C would make things easier. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] GSoC ideas
On Fri, 2013-04-26 at 22:05 +0200, Thomas Martitz wrote: > Am 26.04.2013 14:54, schrieb David Henningsson: > >>> > >>> 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. > > > > 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. > > > How could you possibly be unhappy about "improving RTP support"? Right > now it's basically unusable (for me, anyway) due to this problem/bug: > https://bugs.freedesktop.org/show_bug.cgi?id=44777 I'd be delighted to have better RTP support. But I think it is somewhat misguided to try to maintain a mature RTP stack within PulseAudio. Full post is at: http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-March/016667.html Summary of that: it makes much more sense to reuse something mature like GStreamer's RTP elements for a large number of reasons such as active maintenance and easy support for compressed output. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] GSoC ideas
On Fri, 26 Apr 2013 22:05:03 +0200 Thomas Martitz wrote: > How could you possibly be unhappy about "improving RTP support"? Right > now it's basically unusable (for me, anyway) due to this problem/bug: > https://bugs.freedesktop.org/show_bug.cgi?id=44777 Is has nothing to do with the flood of packages by pulse. This problem is located on your routers/APs because most routers does not support IGMP_snooping and/or changing multicastrates or basicrates (wifi settings). This is a bug within your router setup (or a feature however you name it). If you raise multicast or basicrate(on most systems raising basicrate will also raise multicast) and/or enable igmp_snooping @ router it will works perfect. But this will not work on most routers and APs, because they neither support igmp snooping nor configurable basicrates or mcastrates. But raising basicrate affects your range of your network, because multicast and broadcast packages are handled on the same way. Raising this rate will force all client to be in the range, where they can receive packets with that rate. That is the trade off changing these rates. I'm using 12mbit/s for nearby all setup. Greetings, Alex -- Alexander Couzens mail: lyn...@base45.de sip/jabber: lyn...@c-base.org mobile: +4915123277221 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] GSoC ideas
Am 26.04.2013 14:54, schrieb David Henningsson: 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. 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. How could you possibly be unhappy about "improving RTP support"? Right now it's basically unusable (for me, anyway) due to this problem/bug: https://bugs.freedesktop.org/show_bug.cgi?id=44777 Best regards. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] GSoC ideas
On Fri, 26 Apr 2013 14:54:19 +0200 David Henningsson wrote: > On 04/26/2013 12:48 PM, Tanu Kaskinen wrote: > > Making module-tunnel-sink reliable would be very welcome. > I'd like to see a rewrite of module-tunnel-sink to use the libpulse API > instead of doing the protocol stuff directly. A rewrite could work much better for a project plan? > 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. replace low latency with reliable latency and it can work. > >> - Implementing profiles for different environments. The user can > >> define a profile for home, work, [...]. Main sink, group of sink > >> (combine sinks). Let say location environments. Another interesting question is, how to define a location? Proof me wrong, but Linux does not have a location service which tells us in which environment we are? Like windows doing it for networks. > >> - Simplified way for scripting pulseaudio and doing basic event > >> handling. Normal (power) user should script their soundsystem. > 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. We have already d-bus as optional dependency :). Just do a lua as module? Just try to be generic enought to add other scripting languages. > 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? I don't like shell scripting. Especially because of escaping-hell. How should shell scripting work? It does not gives us a solution for the events. From where we get events? > >> - 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 > > > > 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 would look for ssh-agent-helpers and how they integrate into all Desktop Environments. Don't think we should discuss here about what is the best or suitable encryption. > I'm not seeing the use case for having PulseAudio handle passwords. Can > somebody enlighten me? In bigger networks than home networks, a co-working space, hackerspace or at work, you want to allow certain people to access one pulseserver, but not everybody. You can only allow it by one cookie or do it over ip-acl. But using ip-acl for dynamic ip address is horrible. A cookie is far to long complex. I would like to start from bottom up. First we need a good mod-tunnel, before it make sense for me to start with most of the other tasks. -- Alexander Couzens mail: lyn...@base45.de sip/jabber: lyn...@c-base.org mobile: +4915123277221 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] GSoC ideas
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 t
Re: [pulseaudio-discuss] GSoC ideas
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 > 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. > >> - 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? > Or, to look at
Re: [pulseaudio-discuss] GSoC ideas
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. 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. - 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. - 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, 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. 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? - 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? -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedeskto
Re: [pulseaudio-discuss] GSoC ideas
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. > - 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). I don't know Murphy[1] well enough yet to be sure, but it might be better to implement such profiles in Murphy. I'm a bit hesitant about making this a GSoC project. We could have a "profile module" based on the current routing system, but I'm not sure that the module would be long-lived. [1] https://01.org/murphy/ > - Classify streams to route them based on properties. Music streams > should be routed to the >(remote) music sink, but system sounds should not. Different routing based on the media.role property is already implemented by module-stream-restore and works out-of-the box. > - Missing gui for profiles and/or properties. New qtgui? or extend > pavucontrol. > - 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. > - 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. > - 'Do you like to grant access to ...'. Extend the native protocol > for this. > - mod-tunnel should support multicast dynamic, but configurable. Mcast > support of cheap APs(most DSL/Cable Routers) are limited to 1 > mbit/s(wifi broadcast rate, which also affects multicast) and most of > them doesn't support IGMP. module-tunnel-sink creates a local proxy for a remote sink. I don't think it's a "tunnel" any more if you use multicast. If you need multicast, we already have module-rtp-send, or if RTP isn't what you want, a new module could be created. I'm generally very unenthusiastic about multicast, though. I'm ignorant about the subject; I'm not aware of any important use cases for multicast, so to me its purpose seems to be just to make things difficult. Please educate me, why is
