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