Re: [pulseaudio-discuss] Handling of port latency offsets

2017-02-16 Thread Georg Chini
On 16.02.2017 12:59, Tanu Kaskinen wrote: On Fri, 2017-02-10 at 14:38 +0100, Georg Chini wrote: Hi, during my work on module-loopback I came upon an issue regarding the handling of the port latency offsets. The functions pa_{source,sink}_get_latency_within_thread() return the latencies

[pulseaudio-discuss] [PATCH v3 0/2] Improve default device policy

2017-02-16 Thread Tanu Kaskinen
The first patch refactors the default sink/source handling code to make it easier to add new conditions to how the default sink and source are chosen. It's not pure refactoring, though: the patch also fixes some cases where change notifications were not sent, and the D-Bus protocol's default

[pulseaudio-discuss] [PATCH v3 2/2] core, device-port: check availability when choosing the default device

2017-02-16 Thread Tanu Kaskinen
It doesn't make sense to use a sink or source whose active port is unavailable, so let's take this into account when choosing the default sink and source. --- No changes in v2 or v3. src/pulsecore/core.c| 16 src/pulsecore/device-port.c | 8 2 files changed,

[pulseaudio-discuss] [PATCH v3 1/2] refactor default sink/source handling

2017-02-16 Thread Tanu Kaskinen
Currently the default sink policy is simple: either the user has configured it explicitly, in which case we always use that as the default, or we pick the sink with the highest priority. The sink priorities are currently static, so there's no need to worry about updating the default sink when sink

Re: [pulseaudio-discuss] Handling of port latency offsets

2017-02-16 Thread Georg Chini
On 16.02.2017 13:10, Georg Chini wrote: On 16.02.2017 12:59, Tanu Kaskinen wrote: On Fri, 2017-02-10 at 14:38 +0100, Georg Chini wrote: Hi, during my work on module-loopback I came upon an issue regarding the handling of the port latency offsets. The functions

Re: [pulseaudio-discuss] combined sink does not work with pulseaudio-dlna

2017-02-16 Thread Tanu Kaskinen
On Wed, 2017-02-15 at 17:25 +0100, Ivan Kanis wrote: > The author of the dlna plugin has told me that the combined sink feature > is not implemented in his module. He has given me an alternative with > the loopback module: > > load-module module-loopback

Re: [pulseaudio-discuss] [PATCH] bluez5-device: Use correct constants for fixed latency in PA_{SINK, SOURCE}_MESSAGE_GET_LATENCY

2017-02-16 Thread Tanu Kaskinen
On Wed, 2017-02-15 at 11:32 +0100, Georg Chini wrote: > The PA_{SINK,SOURCE}_GET_LATENCY message handlers falsely always added the > A2DP latency as fixed > latency instead of the profile specific constant. > > --- > src/modules/bluetooth/module-bluez5-device.c | 4 ++-- > 1 file changed, 2

Re: [pulseaudio-discuss] Handling of port latency offsets

2017-02-16 Thread Tanu Kaskinen
On Fri, 2017-02-10 at 14:38 +0100, Georg Chini wrote: > Hi, > > during my work on module-loopback I came upon an issue regarding the > handling > of the port latency offsets. > The functions pa_{source,sink}_get_latency_within_thread() return the > latencies > including the offset. Those

Re: [pulseaudio-discuss] combined sink does not work with pulseaudio-dlna

2017-02-16 Thread Georg Chini
On 16.02.2017 11:50, Tanu Kaskinen wrote: On Wed, 2017-02-15 at 17:25 +0100, Ivan Kanis wrote: The author of the dlna plugin has told me that the combined sink feature is not implemented in his module. He has given me an alternative with the loopback module: load-module module-loopback

Re: [pulseaudio-discuss] Access control

2017-02-16 Thread Tanu Kaskinen
On Wed, 2017-02-15 at 11:34 +0100, Timothy Hobbs wrote: > Obviously, this question reveals my total ignorance of pulseaudio > architecture, but why are you implementing access control in pulseaudio > itself, rather than using a firewall wrapper that parses the info being > sent down the pulse

Re: [pulseaudio-discuss] Pulse audio's UNIX sockets and other questions about pulse and containers

2017-02-16 Thread Tanu Kaskinen
On Fri, 2017-02-10 at 19:08 +0100, Timothy Hobbs wrote: > Hello, > > I'm trying to discover the best way to share pulse audio between linux > containers. I have found a great deal of answers to this problem online. > Some of them involve sharing UNIX sockets, while others suggest > connecting