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 multicast important for any PulseAudio user? What would be
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
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 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
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 too much
Re: [pulseaudio-discuss] GSoC ideas
On Fri, 26 Apr 2013 14:54:19 +0200 David Henningsson david.hennings...@canonical.com 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
[pulseaudio-discuss] [PATCH 1/3] bluetooth: Add 'bluez.alias' property
From: João Paulo Rechi Vita jprv...@openbossa.org
---
As already discussed with Tanuk and Mikel, this series should be applied to the
master branch.
src/modules/bluetooth/module-bluetooth-device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/modules/bluetooth/module-bluetooth-device.c
b/src/modules/bluetooth/module-bluetooth-device.c
index c877df2..8695c80 100644
--- a/src/modules/bluetooth/module-bluetooth-device.c
+++ b/src/modules/bluetooth/module-bluetooth-device.c
@@ -2243,6 +2243,7 @@ static int add_card(struct userdata *u) {
pa_proplist_sets(data.proplist, bluez.path, device-path);
pa_proplist_setf(data.proplist, bluez.class, 0x%06x, (unsigned)
device-class);
pa_proplist_sets(data.proplist, bluez.name, device-name);
+pa_proplist_sets(data.proplist, bluez.alias, device-alias);
data.name = get_name(card, u-modargs, device-address, b);
data.namereg_fail = b;
--
1.7.11.7
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH 2/3] bluetooth: Use 'Alias' value as the device description
From: João Paulo Rechi Vita jprv...@openbossa.org
The 'Alias' property should be preffered over the 'Name' property, according to
the org.bluez.Device1 API documentation.
---
src/modules/bluetooth/module-bluetooth-device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/modules/bluetooth/module-bluetooth-device.c
b/src/modules/bluetooth/module-bluetooth-device.c
index 8695c80..11c6e5f 100644
--- a/src/modules/bluetooth/module-bluetooth-device.c
+++ b/src/modules/bluetooth/module-bluetooth-device.c
@@ -2229,7 +2229,7 @@ static int add_card(struct userdata *u) {
data.driver = __FILE__;
data.module = u-module;
-n = pa_bluetooth_cleanup_name(device-name);
+n = pa_bluetooth_cleanup_name(device-alias);
pa_proplist_sets(data.proplist, PA_PROP_DEVICE_DESCRIPTION, n);
pa_xfree(n);
pa_proplist_sets(data.proplist, PA_PROP_DEVICE_STRING, device-address);
--
1.7.11.7
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH 3/3] bluetooth: Remove the 'bluez.name' property
From: João Paulo Rechi Vita jprv...@openbossa.org
The org.bluez.Device1.Name property is optional and may not be present
(that happens with the PTS 4.7.0), so it's better not to expose it to
clients so they don't rely on its existence.
---
src/modules/bluetooth/module-bluetooth-device.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/modules/bluetooth/module-bluetooth-device.c
b/src/modules/bluetooth/module-bluetooth-device.c
index 11c6e5f..542f0af 100644
--- a/src/modules/bluetooth/module-bluetooth-device.c
+++ b/src/modules/bluetooth/module-bluetooth-device.c
@@ -2242,7 +2242,6 @@ static int add_card(struct userdata *u) {
pa_proplist_sets(data.proplist, bluez.path, device-path);
pa_proplist_setf(data.proplist, bluez.class, 0x%06x, (unsigned)
device-class);
-pa_proplist_sets(data.proplist, bluez.name, device-name);
pa_proplist_sets(data.proplist, bluez.alias, device-alias);
data.name = get_name(card, u-modargs, device-address, b);
data.namereg_fail = b;
--
1.7.11.7
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/3] bluetooth: Add 'bluez.alias' property
On Fri, Apr 26, 2013 at 12:30 PM, jprv...@gmail.com wrote:
From: João Paulo Rechi Vita jprv...@openbossa.org
---
As already discussed with Tanuk and Mikel, this series should be applied to
the
master branch.
And I guess to the next branch as well, so we can rebase the other
bluetooth series on top of it.
src/modules/bluetooth/module-bluetooth-device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/modules/bluetooth/module-bluetooth-device.c
b/src/modules/bluetooth/module-bluetooth-device.c
index c877df2..8695c80 100644
--- a/src/modules/bluetooth/module-bluetooth-device.c
+++ b/src/modules/bluetooth/module-bluetooth-device.c
@@ -2243,6 +2243,7 @@ static int add_card(struct userdata *u) {
pa_proplist_sets(data.proplist, bluez.path, device-path);
pa_proplist_setf(data.proplist, bluez.class, 0x%06x, (unsigned)
device-class);
pa_proplist_sets(data.proplist, bluez.name, device-name);
+pa_proplist_sets(data.proplist, bluez.alias, device-alias);
data.name = get_name(card, u-modargs, device-address, b);
data.namereg_fail = b;
--
1.7.11.7
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 3/3] bluetooth: Remove the 'bluez.name' property
Hi João Paulo,
On Fri, Apr 26, 2013 at 5:30 PM, jprv...@gmail.com wrote:
From: João Paulo Rechi Vita jprv...@openbossa.org
The org.bluez.Device1.Name property is optional and may not be present
(that happens with the PTS 4.7.0), so it's better not to expose it to
clients so they don't rely on its existence.
---
src/modules/bluetooth/module-bluetooth-device.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/modules/bluetooth/module-bluetooth-device.c
b/src/modules/bluetooth/module-bluetooth-device.c
index 11c6e5f..542f0af 100644
--- a/src/modules/bluetooth/module-bluetooth-device.c
+++ b/src/modules/bluetooth/module-bluetooth-device.c
@@ -2242,7 +2242,6 @@ static int add_card(struct userdata *u) {
pa_proplist_sets(data.proplist, bluez.path, device-path);
pa_proplist_setf(data.proplist, bluez.class, 0x%06x, (unsigned)
device-class);
-pa_proplist_sets(data.proplist, bluez.name, device-name);
pa_proplist_sets(data.proplist, bluez.alias, device-alias);
data.name = get_name(card, u-modargs, device-address, b);
data.namereg_fail = b;
--
Ack from my side to the three patches, also for the master branch.
As a minor improvement, the commit messages in patches 2 and 3 could
avoid referring to the org.bluez.Device1 interface, which is BlueZ
5-specific. In particular, the commit message in this patch should
mention that this is future-proof, even though BlueZ 5 is not
supported yet (given that the property is actually *not* optional in
BlueZ 4).
Cheers,
Mikel
___
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
[pulseaudio-discuss] Integrating with ALSA
Hi,
I am trying to integrate PA with ALSA.
I just changed the alsa.conf to add
pcm.!default {
type pulse
}
pcm.pulse {
type pulse
}
ctl.pulse {
type pulse
}
but i am landing into this error
# aplay -Dpulse /share/t.wav
ALSA lib dlmisc.c:236:(snd1_dlobj_cache_get) Cannot open shared library
/usr/lib/alsa-lib/libasound_module_pcm_pulse.so
aplay: main:696: audio open error: No such device or address
Though i am lacking this lib but it seems like i do not actually need this
lib ? . Am i missing something here ?
thanks,
Keith
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] bluetooth: Remove the 'bluez.name' property
From: João Paulo Rechi Vita jprv...@openbossa.org
The 'Name' property of the Device interface became optional in BlueZ 5
and may not be present anymore (that happens when testing against the
PTS 4.7.0), so it's better not to expose it to clients so they don't
rely on its existence.
---
src/modules/bluetooth/module-bluetooth-device.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/modules/bluetooth/module-bluetooth-device.c
b/src/modules/bluetooth/module-bluetooth-device.c
index 11c6e5f..542f0af 100644
--- a/src/modules/bluetooth/module-bluetooth-device.c
+++ b/src/modules/bluetooth/module-bluetooth-device.c
@@ -2242,7 +2242,6 @@ static int add_card(struct userdata *u) {
pa_proplist_sets(data.proplist, bluez.path, device-path);
pa_proplist_setf(data.proplist, bluez.class, 0x%06x, (unsigned)
device-class);
-pa_proplist_sets(data.proplist, bluez.name, device-name);
pa_proplist_sets(data.proplist, bluez.alias, device-alias);
data.name = get_name(card, u-modargs, device-address, b);
data.namereg_fail = b;
--
1.7.11.7
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] bluetooth: Use 'Alias' value as the device description
From: João Paulo Rechi Vita jprv...@openbossa.org
The 'Alias' property should be preffered over the 'Name' property,
according to the BlueZ API documentation.
---
src/modules/bluetooth/module-bluetooth-device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/modules/bluetooth/module-bluetooth-device.c
b/src/modules/bluetooth/module-bluetooth-device.c
index 8695c80..11c6e5f 100644
--- a/src/modules/bluetooth/module-bluetooth-device.c
+++ b/src/modules/bluetooth/module-bluetooth-device.c
@@ -2229,7 +2229,7 @@ static int add_card(struct userdata *u) {
data.driver = __FILE__;
data.module = u-module;
-n = pa_bluetooth_cleanup_name(device-name);
+n = pa_bluetooth_cleanup_name(device-alias);
pa_proplist_sets(data.proplist, PA_PROP_DEVICE_DESCRIPTION, n);
pa_xfree(n);
pa_proplist_sets(data.proplist, PA_PROP_DEVICE_STRING, device-address);
--
1.7.11.7
___
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 ku...@rockbox.org 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
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, 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
