On 19.02.2018 15:48, Tanu Kaskinen wrote:
build_pollfd() isn't likely to fail, but if it does, pa_sink/source_put()
will crash on an assertion failure. I haven't seen such crash happening,
this is just something that I noticed while studying the state change
code.
---
On Wed, 2018-02-21 at 09:40 +0100, Georg Chini wrote:
> On 19.02.2018 15:48, Tanu Kaskinen wrote:
> > pa_sink_get_state() is supposed to be used from the main thread. In this
> > case it doesn't really matter, because the SET_STATE handler is executed
> > while the main thread is waiting, but
On 02/21/2018 09:39 AM, Georg Chini wrote:
> On 21.02.2018 06:05, Georg Chini wrote:
>> On 21.02.2018 05:55, Georg Chini wrote:
>>> On 20.02.2018 22:34, Raman Shishniou wrote:
On 02/20/2018 11:04 PM, Georg Chini wrote:
> On 20.02.2018 19:49, Raman Shishniou wrote:
>> On 02/20/2018
On 19.02.2018 15:48, Tanu Kaskinen wrote:
Suspending never fails.
---
src/modules/alsa/alsa-sink.c | 9 ++---
src/modules/alsa/alsa-source.c | 9 ++---
src/modules/module-solaris.c | 18 +++---
src/modules/oss/module-oss.c | 16 +---
4 files changed,
pa_sink_get_state() is supposed to be used from the main thread. In this
case it doesn't really matter, because the SET_STATE handler is executed
while the main thread is waiting, but since the state is available also
in thread_info, let's use that. All other modules use thread_info.state
too, so
On 21.02.2018 10:54, Tanu Kaskinen wrote:
pa_sink_get_state() is supposed to be used from the main thread. In this
case it doesn't really matter, because the SET_STATE handler is executed
while the main thread is waiting, but since the state is available also
in thread_info, let's use that. All
On Mon, 2018-02-19 at 17:21 +0100, Andreas Hartmetz wrote:
> Am Montag, 19. Februar 2018, 17:05:27 CET schrieben Sie:
> > On 02/19/2018 06:46 PM, Andreas Hartmetz wrote:
> > > Hello!
> > >
> > > I am currently developing an audio system for an automotive
> > > customer,
> > > based on PulseAudio
On 21.02.2018 12:50, Raman Shishniou wrote:
On 02/21/2018 02:24 PM, Georg Chini wrote:
On 21.02.2018 12:22, Raman Shishniou wrote:
On 02/21/2018 12:13 PM, Raman Shishniou wrote:
On 02/21/2018 09:39 AM, Georg Chini wrote:
On 21.02.2018 06:05, Georg Chini wrote:
On 21.02.2018 05:55, Georg
On 02/21/2018 05:00 PM, Georg Chini wrote:
> On 21.02.2018 12:50, Raman Shishniou wrote:
>> On 02/21/2018 02:24 PM, Georg Chini wrote:
>>> On 21.02.2018 12:22, Raman Shishniou wrote:
On 02/21/2018 12:13 PM, Raman Shishniou wrote:
> On 02/21/2018 09:39 AM, Georg Chini wrote:
>> On
On 21.02.2018 15:33, Raman Shishniou wrote:
On 02/21/2018 05:00 PM, Georg Chini wrote:
On 21.02.2018 12:50, Raman Shishniou wrote:
On 02/21/2018 02:24 PM, Georg Chini wrote:
On 21.02.2018 12:22, Raman Shishniou wrote:
On 02/21/2018 12:13 PM, Raman Shishniou wrote:
On 02/21/2018 09:39 AM,
On 02/21/2018 09:41 PM, Raman Shuishniou wrote:
> 21.02.2018 20:07, Georg Chini пишет:
>> Maybe you misunderstood me. What I mean, is that the pipe can be
>> opened for writing as long as we are suspended. So it open when
>> we see that the source is suspended or when we auto suspend. Close
>> it
On Thu, 2018-02-22 at 08:25 +0100, Georg Chini wrote:
> On 19.02.2018 15:48, Tanu Kaskinen wrote:
> > The suspend cause isn't yet used by any of the handlers. The alsa sink
> > and source will use it to sync the mixer when the SESSION suspend cause
> > is removed. Currently the syncing is done in
On 19.02.2018 15:48, Tanu Kaskinen wrote:
The suspend cause isn't yet used by any of the handlers. The alsa sink
and source will use it to sync the mixer when the SESSION suspend cause
is removed. Currently the syncing is done in pa_sink/source_suspend(),
and I want to change that, because
On 19.02.2018 15:48, Tanu Kaskinen wrote:
When resuming a sink or source, pa_sink/source_process_msg() should be
called only if resuming is successful. pa_sink/source_process_msg()
updates thread_info.state and notifies streams about the new state, but
if resuming fails, there's no state change.
On 02/21/2018 05:59 PM, Georg Chini wrote:
> On 21.02.2018 15:33, Raman Shishniou wrote:
>> On 02/21/2018 05:00 PM, Georg Chini wrote:
>>> On 21.02.2018 12:50, Raman Shishniou wrote:
On 02/21/2018 02:24 PM, Georg Chini wrote:
> On 21.02.2018 12:22, Raman Shishniou wrote:
>> On
Am Mittwoch, 21. Februar 2018, 11:24:17 CET schrieb Tanu Kaskinen:
> On Mon, 2018-02-19 at 17:21 +0100, Andreas Hartmetz wrote:
> > Am Montag, 19. Februar 2018, 17:05:27 CET schrieben Sie:
> > > On 02/19/2018 06:46 PM, Andreas Hartmetz wrote:
> > > > Hello!
> > > >
> > > > I am currently
On 21.02.2018 16:15, Raman Shishniou wrote:
On 02/21/2018 05:59 PM, Georg Chini wrote:
On 21.02.2018 15:33, Raman Shishniou wrote:
On 02/21/2018 05:00 PM, Georg Chini wrote:
On 21.02.2018 12:50, Raman Shishniou wrote:
On 02/21/2018 02:24 PM, Georg Chini wrote:
On 21.02.2018 12:22, Raman
On 02/21/2018 06:43 PM, Georg Chini wrote:
> On 21.02.2018 16:15, Raman Shishniou wrote:
>> On 02/21/2018 05:59 PM, Georg Chini wrote:
>>> On 21.02.2018 15:33, Raman Shishniou wrote:
On 02/21/2018 05:00 PM, Georg Chini wrote:
> On 21.02.2018 12:50, Raman Shishniou wrote:
>> On
On 02/21/2018 12:13 PM, Raman Shishniou wrote:
> On 02/21/2018 09:39 AM, Georg Chini wrote:
>> On 21.02.2018 06:05, Georg Chini wrote:
>>> On 21.02.2018 05:55, Georg Chini wrote:
On 20.02.2018 22:34, Raman Shishniou wrote:
> On 02/20/2018 11:04 PM, Georg Chini wrote:
>> On 20.02.2018
On Sun, 2018-01-28 at 18:40 +0100, Georg Chini wrote:
> This patch adds the PA_COMMAND_SEND_OBJECT_MESSAGE command to protocol-native
> so that clients can use the messaging feature introduced in the previous
> patch.
>
> Sending messages can in effect replace the extension system for modules.
On 21.02.2018 12:22, Raman Shishniou wrote:
On 02/21/2018 12:13 PM, Raman Shishniou wrote:
On 02/21/2018 09:39 AM, Georg Chini wrote:
On 21.02.2018 06:05, Georg Chini wrote:
On 21.02.2018 05:55, Georg Chini wrote:
On 20.02.2018 22:34, Raman Shishniou wrote:
On 02/20/2018 11:04 PM, Georg
On 02/21/2018 02:24 PM, Georg Chini wrote:
> On 21.02.2018 12:22, Raman Shishniou wrote:
>> On 02/21/2018 12:13 PM, Raman Shishniou wrote:
>>> On 02/21/2018 09:39 AM, Georg Chini wrote:
On 21.02.2018 06:05, Georg Chini wrote:
> On 21.02.2018 05:55, Georg Chini wrote:
>> On 20.02.2018
On Tue, 2018-02-13 at 20:06 +0100, Bert Hekman wrote:
> ---
> src/modules/alsa/alsa-mixer.c | 2 ++
> .../paths/steelseries-arctis-5-output-chat.conf| 27
> ++
> .../paths/steelseries-arctis-5-output-game.conf| 27
> ++
>
On 02/19/2018 05:48 PM, Tanu Kaskinen wrote:
> The suspend cause isn't yet used by any of the handlers. The alsa sink
> and source will use it to sync the mixer when the SESSION suspend cause
> is removed. Currently the syncing is done in pa_sink/source_suspend(),
> and I want to change that,
On 21.02.2018 17:09, Raman Shishniou wrote:
On 02/21/2018 06:43 PM, Georg Chini wrote:
On 21.02.2018 16:15, Raman Shishniou wrote:
On 02/21/2018 05:59 PM, Georg Chini wrote:
On 21.02.2018 15:33, Raman Shishniou wrote:
On 02/21/2018 05:00 PM, Georg Chini wrote:
On 21.02.2018 12:50, Raman
21.02.2018 20:07, Georg Chini пишет:
Maybe you misunderstood me. What I mean, is that the pipe can be
opened for writing as long as we are suspended. So it open when
we see that the source is suspended or when we auto suspend. Close
it as soon as the source gets unsuspended. This will avoid
On 21.02.2018 20:15, Raman Shishniou wrote:
On 02/21/2018 09:41 PM, Raman Shuishniou wrote:
21.02.2018 20:07, Georg Chini пишет:
Maybe you misunderstood me. What I mean, is that the pipe can be
opened for writing as long as we are suspended. So it open when
we see that the source is suspended
On 19.02.2018 15:48, Tanu Kaskinen wrote:
This adds a pa_suspend_cause_t parameter to the sink/source_set_state()
functions, and moves part of the work that pa_sink/source_suspend() does
to sink/source_set_state(). The reason for this code shuffling is that I
plan to make all suspend cause
On 19.02.2018 15:48, Tanu Kaskinen wrote:
The suspend cause isn't yet used by any of the callbacks. The alsa sink
and source will use it to sync the mixer when the SESSION suspend cause
is removed. Currently the syncing is done in pa_sink/source_suspend(),
and I want to change that, because
29 matches
Mail list logo
