On Sun, Jan 10, 2016 at 07:08:51PM +0100, Michał Zegan wrote:
>
> W dniu 10.01.2016 o 18:53, Reindl Harald pisze:
> >
> > Am 10.01.2016 um 18:42 schrieb Tom Yan:
> > > Ugh I am not talking about system units, but user units...
> > >
> > > P.S. Although not really relevant here, but I am using the
The only thing seems to be you cannot go low latency with system mode
pulseaudio
W dniu 10.01.2016 o 18:53, Reindl Harald pisze:
Am 10.01.2016 um 18:42 schrieb Tom Yan:
Ugh I am not talking about system units, but user units...
P.S. Although not really relevant here, but I am using the (use
Am 10.01.2016 um 18:42 schrieb Tom Yan:
Ugh I am not talking about system units, but user units...
P.S. Although not really relevant here, but I am using the (user)
service file provided by upstream pulseaudio
well, and i am talking about solutions and working setups
and yes i know that sys
Ugh I am not talking about system units, but user units...
P.S. Although not really relevant here, but I am using the (user)
service file provided by upstream pulseaudio
On 11 January 2016 at 01:30, Reindl Harald wrote:
>
>
> Am 10.01.2016 um 18:15 schrieb Mantas Mikulėnas:
>>
>> I remember this
Am 10.01.2016 um 18:15 schrieb Mantas Mikulėnas:
I remember this discussed before, I think one suggestion was to split
into two targets, and only hold the login until the first target. Nobody
implemented it though.
But yes, pulseaudio.socket would be a requirement of that. If you don't
want to
That's exactly what I meant. There should be a target for units that
"need to be waited" and "no need to be waited" respectively. One can
argue which one should a sound service fall into with whatever point,
but that's out of the scope of the issue I am talking about here.
I just thought systemd h
I remember this discussed before, I think one suggestion was to split into
two targets, and only hold the login until the first target. Nobody
implemented it though.
But yes, pulseaudio.socket would be a requirement of that. If you don't
want to wait until it starts, *and* don't want to socket-act
10.01.2016 17:25, Tom Yan пишет:
> So I am recently experiencing some issue with pulseaudio (which I
> already filed a bug report:
> https://bugs.freedesktop.org/show_bug.cgi?id=93651) that it takes a
> long time to start.
>
> The thing is, I am thinking whether it exposed a problem of systemd as
So I am recently experiencing some issue with pulseaudio (which I
already filed a bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=93651) that it takes a
long time to start.
The thing is, I am thinking whether it exposed a problem of systemd as
well. For example:
Jan 10 21:31:33 localhost
On Sun, Jan 10, 2016, at 02:01 AM, Robert O'Callahan wrote:
>>
> Thanks. Unfortunately prctl(PR_SET_DUMPABLE, 0) makes it impossible to
> PTRACE_ATTACH to such a process, which rr needs to run its tests. (rr
> is a debugger.). It also changes the owner of most files/dirs under
> /proc/ to root, whi
On Sun, Jan 10, 2016 at 02:45:30PM +0200, Moreanu Robert - Nicolae wrote:
> how i would resolve this
>
> user system [474]: Failed at step EXEC spawning /usr/sbin/alsactl: No such
> file or directory
> - subject: Process /usr/sbin/alsactl could not be executed
> - The process /usr/sbin/alsactl cou
how i would resolve this
user system [474]: Failed at step EXEC spawning /usr/sbin/alsactl: No such
file or directory
- subject: Process /usr/sbin/alsactl could not be executed
- Defined-By: systemd
- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-
- The process /usr/sbin/al
12 matches
Mail list logo
