Re: [LAD] AVB not so dead after all
Hello Reuben, I have been talking to a Intel guy at the last AES convention and he told me they are supporting AVB (maybe he's reading this list as well). Another strong signal regarding AVB not dead. We were specifically talking about audio networking and multimedia. Best -- Leonardo Gabrielli, PhD Research Fellow A3Lab - DII - Università Politecnica delle Marche, Ancona, Italy skype: leonardo.gabrielli ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AVB not so dead after all
On Sun, Jun 7, 2015 at 10:15 AM, Len Ovens wrote: > I was "listening in" on a IRC conversation about the differences between > ALSA and Core audio and why Core audio "does it right". The difference ends > up being this HW clock. That is ALSA is build the way it is because the PC > requires it to be. > This isn't true. I'm not sure what you're thinking of/referring to. ___ 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
Just out of interest: why are you trying to run jack as root?
Gerald
On 06.06.2015 23:08, Tito Latini wrote:
> 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
___
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 Mon, Jun 8, 2015 at 10:18 PM, Gerald wrote: > Just out of interest: why are you trying to run jack as root? $ whoami root I am root, a user who likes to run JACK for audio :) Cheers, -Harry PS: Yes I'm aware of security concerns etc -- http://www.openavproductions.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AVB not so dead after all
On 06/07/2015 07:15 AM, Len Ovens wrote: ... Why is this? Linux is based on lowest common denominator hardware... we call it the PC. The Linux world has gotten much better preformance out of this box than it was designed for. But, in the case of audio, the HW does limit performance at least with AoIP. That limit is the clock. The PC does not have a HW PTP clock built in and in this case software is not good enough. The way around this is with a custom NIC that does. For some reason even though one can buy an ethernet chip that includes a stable PTP clock for less than $5, any NICs I have found with a PTP clock are closer to $1k. An Intel I210 Gigabit Ethernet PCI express Card will set you back about $70 on Newegg, it does have the hardware support that AVB needs and a driver in the OpenAVB project. I have a couple and they seem to work just fine. A 24 output AVB Motu box is $995. I'm actually trying to get this going with one of these AO24 Motu "soundcards" (starting with OpenAVB). I have gotten as far as the OpenAVB stack talking to the Motu card and slaving its clock to it (and the Motu box recognizing it is now the master clock source and AVB is active). Audio streaming is next, I'm just not finding the free time to do this (anyone gotten further along on this??). First goal would be a simple jack client that can stream samples, end game would be a jack backend so this can be treated as a soundcard. We'll see... -- Fernando ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AVB not so dead after all
Sounds awesome Fernando. I have a few of the XMOS AVB endpoints I am not using if anyone wants one. On Mon, Jun 8, 2015 at 7:14 PM, Fernando Lopez-Lezcano < na...@ccrma.stanford.edu> wrote: > On 06/07/2015 07:15 AM, Len Ovens wrote: > ... > >> Why is this? Linux is based on lowest common denominator hardware... we >> call it the PC. The Linux world has gotten much better preformance out >> of this box than it was designed for. But, in the case of audio, the HW >> does limit performance at least with AoIP. That limit is the clock. The >> PC does not have a HW PTP clock built in and in this case software is >> not good enough. The way around this is with a custom NIC that does. For >> some reason even though one can buy an ethernet chip that includes a >> stable PTP clock for less than $5, any NICs I have found with a PTP >> clock are closer to $1k. >> > > An Intel I210 Gigabit Ethernet PCI express Card will set you back about > $70 on Newegg, it does have the hardware support that AVB needs and a > driver in the OpenAVB project. I have a couple and they seem to work just > fine. A 24 output AVB Motu box is $995. > > I'm actually trying to get this going with one of these AO24 Motu > "soundcards" (starting with OpenAVB). I have gotten as far as the OpenAVB > stack talking to the Motu card and slaving its clock to it (and the Motu > box recognizing it is now the master clock source and AVB is active). Audio > streaming is next, I'm just not finding the free time to do this (anyone > gotten further along on this??). > > First goal would be a simple jack client that can stream samples, end game > would be a jack backend so this can be treated as a soundcard. We'll see... > > -- Fernando > > ___ > 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
