Re: [LAD] JACK and vanilla 3.19.2 startup issue
On Sat, Apr 4, 2015 at 8:13 PM, Adrian Knoth
wrote:
> Not enough information. I recommend starting jackd with strace
>
Done - apologies for the delay. Strace output available[1], but the most
interesting part copied here:
sched_get_priority_min(SCHED_FIFO) = 1
sched_setscheduler(0, SCHED_FIFO, { 1 }) = -1 EPERM (Operation not
permitted)
write(2, "\nJACK is running in realtime mod"..., 87
JACK is running in realtime mode, but you are not allowed to use realtime
scheduling.
) = 87
> This code tries to call sched_setscheduler() with SCHED_FIFO. My bet is
> that your "almost vanilla kernel" fails to fulfil this request, but
> strace will tell you for sure.
>
By "almost vanilla" I meant the Arch linux packaged version - I didn't
change the config myself (and Arch aims to be true to vanilla). A very
accurace prediction though - indeed sched_setscheduler() is causing a
return of -1. This is running as root though - so something is wrong here.
> The question is why said call should fail. The only thing that comes to
> my mind are CGROUPS. Maybe your old kernel comes without, the new kernel
> supports them and the configuration is set in a way that disables
> SCHED_FIFO by default.
>
Perhaps - I'm not experienced with cgroups or such, if anybody has any test
ideas for me I'll try them out?
Cheers, -Harry
[1] http://openavproductions.com/tmp/straceJackd.txt
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK and vanilla 3.19.2 startup issue
I meet maybe the same problem under fedora: I added myself to the
pulse-rt group.
This group has priorities defined in /etc/security/limits.d/95-jack.conf
@jackuser - rtprio 95
@jackuser - memlock unlimited
#@audio- rtprio 95
#@audio- memlock unlimited
#@pulse-rt - rtprio 10
#@pulse-rt - nice -20
And because I belong to the jackuser and pulse-rt group, the lower
rtprio was retained.
If I commented the pulse-rt part of 95-jack.conf everything was back to
normal.
YC
Le 06/06/2015 16:35, Harry van Haaren a écrit :
On Sat, Apr 4, 2015 at 8:13 PM, Adrian Knoth
mailto:a...@drcomp.erfurt.thur.de>> wrote:
Not enough information. I recommend starting jackd with strace
Done - apologies for the delay. Strace output available[1], but the
most interesting part copied here:
sched_get_priority_min(SCHED_FIFO) = 1
sched_setscheduler(0, SCHED_FIFO, { 1 }) = -1 EPERM (Operation not
permitted)
write(2, "\nJACK is running in realtime mod"..., 87
JACK is running in realtime mode, but you are not allowed to use
realtime scheduling.
) = 87
This code tries to call sched_setscheduler() with SCHED_FIFO. My
bet is
that your "almost vanilla kernel" fails to fulfil this request, but
strace will tell you for sure.
By "almost vanilla" I meant the Arch linux packaged version - I didn't
change the config myself (and Arch aims to be true to vanilla). A very
accurace prediction though - indeed sched_setscheduler() is causing a
return of -1. This is running as root though - so something is wrong here.
The question is why said call should fail. The only thing that
comes to
my mind are CGROUPS. Maybe your old kernel comes without, the new
kernel
supports them and the configuration is set in a way that disables
SCHED_FIFO by default.
Perhaps - I'm not experienced with cgroups or such, if anybody has any
test ideas for me I'll try them out?
Cheers, -Harry
[1] http://openavproductions.com/tmp/straceJackd.txt
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK and vanilla 3.19.2 startup issue
You can use your own systemd --user service for it (to circumvent all
the weird dbus stuff).
Talked about this at this year's LAC.
http://lac.linuxaudio.org/2015/download/lac2015_arch_slides.pdf
For reference (you can get the package from the AUR, it's called uenv-git):
https://git.sleepmap.de/uenv.git/tree/user/jack@.service
https://git.sleepmap.de/uenv.git/tree/config/fw1
On 06.06.2015 16:35, Harry van Haaren wrote:
> On Sat, Apr 4, 2015 at 8:13 PM, Adrian Knoth
> mailto:a...@drcomp.erfurt.thur.de>> wrote:
>
> Not enough information. I recommend starting jackd with strace
>
> Done - apologies for the delay. Strace output available[1], but the
> most interesting part copied here:
>
> sched_get_priority_min(SCHED_FIFO) = 1
> sched_setscheduler(0, SCHED_FIFO, { 1 }) = -1 EPERM (Operation not
> permitted)
> write(2, "\nJACK is running in realtime mod"..., 87
> JACK is running in realtime mode, but you are not allowed to use
> realtime scheduling.
> ) = 87
>
>
>
> This code tries to call sched_setscheduler() with SCHED_FIFO. My
> bet is
> that your "almost vanilla kernel" fails to fulfil this request, but
> strace will tell you for sure.
>
> By "almost vanilla" I meant the Arch linux packaged version - I didn't
> change the config myself (and Arch aims to be true to vanilla). A very
> accurace prediction though - indeed sched_setscheduler() is causing a
> return of -1. This is running as root though - so something is wrong here.
>
>
> The question is why said call should fail. The only thing that
> comes to
> my mind are CGROUPS. Maybe your old kernel comes without, the new
> kernel
> supports them and the configuration is set in a way that disables
> SCHED_FIFO by default.
>
> Perhaps - I'm not experienced with cgroups or such, if anybody has any
> test ideas for me I'll try them out?
>
> Cheers, -Harry
>
> [1] http://openavproductions.com/tmp/straceJackd.txt
>
>
>
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
David Runge
Köpenicker Straße 163
10997 Berlin
http://www.sleepmap.de
signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] question re: waf cprogram
On 05/29/2015 12:23 PM, David Robillard wrote: On Fri, 2015-05-29 at 08:06 -0400, Dave Phillips wrote: Greetings, The error and repair attached below come from my attempts to build gmidimonitor on Fedora 19. As you can see, gcc is not what's required to complete the build, but waf's cprogram calls gcc, not g++. Alas, I can't find much information about the cprogram directive, and I'm always out of my depths when C++ is involved. Before anyone decides it's an "old code" issue, be advised that I have to perform the same operation on the latest git pulls of xjadeo. I'd like to know if there's a global solution, or at least a compile-time export I can use to resolve the problem. Use cxxprogram for c++, not cprogram Thanks, Dave ! Best, dp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] question re: waf cprogram
On 05/29/2015 10:41 AM, Charles Z Henry wrote:
It looks to me like the linking is just missing libstdc++. "gcc"
would work fine except for missing "-lstdc++"
Chuck
Thanks, Chuck !
Best,
dp
On Fri, May 29, 2015 at 7:06 AM, Dave Phillips wrote:
Greetings,
The error and repair attached below come from my attempts to build
gmidimonitor on Fedora 19. As you can see, gcc is not what's required to
complete the build, but waf's cprogram calls gcc, not g++. Alas, I can't
find much information about the cprogram directive, and I'm always out of my
depths when C++ is involved.
Before anyone decides it's an "old code" issue, be advised that I have to
perform the same operation on the latest git pulls of xjadeo.
I'd like to know if there's a global solution, or at least a compile-time
export I can use to resolve the problem.
Fedora 19 x86_64, GCC 4.8.3
TIA!
Best,
dp
[dlphilp@localhost gmidimonitor-3.6]$ ./waf
Waf: Entering directory `/home/dlphilp/src/gmidimonitor-3.6/build'
[10/10] cprogram: build/main.c.0.o build/about.c.0.o build/path.c.0.o
build/gm.c.0.o build/log.c.0.o build/memory_atomic.c.0.o build/sysex.c.0.o
build/jack.c.0.o build/alsa.c.0.o -> build/gmidimonitor
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/libjack.so:
undefined reference to
`std::__detail::_List_node_base::_M_unhook()@GLIBCXX_3.4.15'
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/libjack.so:
undefined reference to
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)@GLIBCXX_3.4.15'
collect2: error: ld returned 1 exit status
Waf: Leaving directory `/home/dlphilp/src/gmidimonitor-3.6/build'
Build failed
-> task failed (exit status 1):
{task 40700176: cprogram
main.c.0.o,about.c.0.o,path.c.0.o,gm.c.0.o,log.c.0.o,memory_atomic.c.0.o,sysex.c.0.o,jack.c.0.o,alsa.c.0.o
-> gmidimonitor}
['gcc', 'main.c.0.o', 'about.c.0.o', 'path.c.0.o', 'gm.c.0.o', 'log.c.0.o',
'memory_atomic.c.0.o', 'sysex.c.0.o', 'jack.c.0.o', 'alsa.c.0.o', '-o',
'/home/dlphilp/src/gmidimonitor-3.6/build/gmidimonitor', '-Wl,-Bstatic',
'-Wl,-Bdynamic', '-lgtk-x11-2.0', '-lgdk-x11-2.0', '-latk-1.0', '-lgio-2.0',
'-lpangoft2-1.0', '-lpangocairo-1.0', '-lgdk_pixbuf-2.0', '-lcairo',
'-lpango-1.0', '-lfreetype', '-lfontconfig', '-lgobject-2.0', '-lglib-2.0',
'-lgthread-2.0', '-lglib-2.0', '-lgmodule-2.0', '-lglib-2.0', '-ljack',
'-lasound', '-llash', '-lpthread', '-luuid', '-ljack', '-lasound',
'-pthread', '-pthread', '-pthread', '-pthread', '-Wl,--export-dynamic',
'-pthread']
[dlphilp@localhost gmidimonitor-3.6]$ cd build/
[dlphilp@localhost build]$ g++ main.c.0.o about.c.0.o path.c.0.o gm.c.0.o
log.c.0.o memory_atomic.c.0.o sysex.c.0.o jack.c.0.o alsa.c.0.o -o
/home/dlphilp/src/gmidimonitor-3.6/build/gmidimonitor -Wl,-Bstatic
-Wl,-Bdynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0
-lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype
-lfontconfig -lgobject-2.0 -lglib-2.0 -lgthread-2.0 -lglib-2.0 -lgmodule-2.0
-lglib-2.0 -ljack -lasound -llash -lpthread -luuid -ljack -lasound -pthread
-pthread -pthread -pthread -Wl,--export-dynamic -pthread
[dlphilp@localhost build]$ ls
about.c.0.o alsa.c.0.o c4che config.h config.log gm.c.0.o gmidimonitor
jack.c.0.o log.c.0.o main.c.0.o memory_atomic.c.0.o path.c.0.o
sysex.c.0.o
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK and vanilla 3.19.2 startup issue
On Sat, Jun 06, 2015 at 03:35:16PM +0100, Harry van Haaren wrote:
> On Sat, Apr 4, 2015 at 8:13 PM, Adrian Knoth
> wrote:
>
> > Not enough information. I recommend starting jackd with strace
> >
> Done - apologies for the delay. Strace output available[1], but the most
> interesting part copied here:
>
> sched_get_priority_min(SCHED_FIFO) = 1
> sched_setscheduler(0, SCHED_FIFO, { 1 }) = -1 EPERM (Operation not
> permitted)
> write(2, "\nJACK is running in realtime mod"..., 87
> JACK is running in realtime mode, but you are not allowed to use realtime
> scheduling.
> ) = 87
>
>
>
> > This code tries to call sched_setscheduler() with SCHED_FIFO. My bet is
> > that your "almost vanilla kernel" fails to fulfil this request, but
> > strace will tell you for sure.
> >
> By "almost vanilla" I meant the Arch linux packaged version - I didn't
> change the config myself (and Arch aims to be true to vanilla). A very
> accurace prediction though - indeed sched_setscheduler() is causing a
> return of -1. This is running as root though - so something is wrong here.
>
>
> > The question is why said call should fail. The only thing that comes to
> > my mind are CGROUPS. Maybe your old kernel comes without, the new kernel
> > supports them and the configuration is set in a way that disables
> > SCHED_FIFO by default.
> >
> Perhaps - I'm not experienced with cgroups or such, if anybody has any test
> ideas for me I'll try them out?
No tested but perhaps the follow lines in __sched_setscheduler
(linux-3.19.8/kernel/sched/core.c) are relevant:
#ifdef CONFIG_RT_GROUP_SCHED
/*
* Do not allow realtime tasks into groups that have no runtime
* assigned.
*/
if (rt_bandwidth_enabled() && rt_policy(policy) &&
task_group(p)->rt_bandwidth.rt_runtime == 0 &&
!task_group_is_autogroup(task_group(p))) {
task_rq_unlock(rq, p, &flags);
return -EPERM;
}
#endif
#ifdef CONFIG_SMP
if (dl_bandwidth_enabled() && dl_policy(policy)) {
cpumask_t *span = rq->rd->span;
/*
* Don't allow tasks with an affinity mask smaller than
* the entire root_domain to become SCHED_DEADLINE. We
* will also fail if there's no bandwidth available.
*/
if (!cpumask_subset(span, &p->cpus_allowed) ||
rq->rd->dl_bw.bw == 0) {
task_rq_unlock(rq, p, &flags);
return -EPERM;
}
}
#endif
However I'm using 3.10 compiled without CONFIG_RT_GROUP_SCHED and the
second `#ifdef' (CONFIG_SMP) is not present in the source code.
Hypothesis: the second condition fails
=> disable the bandwidth management logic (the default is 95):
echo -1 > /proc/sys/kernel/sched_rt_runtime_us
More info about sched_rt_runtime_us:
scheduler/sched-rt-group.txt: "2.1 System wide settings"
scheduler/sched-deadline.txt: "4.1 System wide settings"
If it continues to fail and your kernel is compiled with
CONFIG_RT_GROUP_SCHED, you could recompile it without this
configuration option (if you don't use realtime group scheduling).
Oh, if it continues to fail, see the other branches with `return -EPERM'
in __sched_setscheduler.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] AVB not so dead after all
I thought I would post this since there was a big conversation here a while back about AES67 and the slow death of AVB due to lack of support. Well I was talking with a guy from Meyer Sound who told me that AVB has been resurrected from the dead. Apparently Cisco and other large network hardware vendors were willing to back it as long as it was made more generic to accommodate industrial uses that are also time-sensitive. So apparently it has been re-branded as “Time-Sensitive Networking” and has a lot more momentum behind it. http://en.wikipedia.org/wiki/Time-Sensitive_Networking http://www.commercialintegrator.com/article/rebranding_avb_4_key_takeaways_from_time_sensitive_networks_conference So make of it what you will. :) I just found it to be interesting. -Reuben ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
