Hi everyone 8)
My new song "No Sister" is out, it's a playful tale of a dying reality.
https://goo.gl/ABbj2W
Basically same production details (Ubuntu LowLatency, Qtractor, Calf,
JAMin) as the other songs on the album.
NB: First time I use Blender VSE
<https://www.blender.org/manual/de/editors/sequencer/index.html> for
video editing, and I'm pretty sure I'll never use anything else again ;
I was just hurting myself.
I Hope you'll enjoy it, it's free. And *please²* *share* it even if you
don't. I know I do :)
Y Phil
--
Philippe "xaccrocheur" Yassin
http://manyrecords.comhttp://bitbucket.org/xaccrocheur /https://github.com/xaccrocheur
Hi,
I noticed that the AUR jack2-git package has got an odd versioning and
perhaps it's more comfortable to name the package jack2, if the package
from git should be just a temporarily solution.
I didn't test the build package, but it builds well, most likely will
work and it might save you some time, if you don't need to edit the
PKGBUILD too.
jack2-git 1.9.10-g1ed50c9 or most likely a more current version from git
too, is needed to get rid of the freewheeling bug, that's why I edited the
AUR jack2-git PKGBUILD. It's a dirty edit, but should work and perhaps is
still more clean than the original jackd2-git,
https://aur.archlinux.org/packages/jack2-git/ ;).
The information is from:
Date: Wed, 24 Feb 2016 00:38:22 +0100
From: Robin Gareus
To: ardour-users(a)lists.ardour.org
Subject: Re: [Ardour-Users] Export hangs after script executing
[snip]
1.9.11 (actually git: 1.9.10-g1ed50c92) is known to be good WRT to this
freewheeling bug.
Arch Linux PKGBUILD:
Ralf_Mardorf commented on 2016-02-27 18:15
https://aur.archlinux.org/pkgbase/jack2-git/#news
Hi,
consider to give the package an appropriated version number.
Instead of
[rocketmouse@archlinux jack2]$ git rev-list --count master
3425
the following to me is more reasonable:
[rocketmouse@archlinux jack2]$ git describe|cut -d"v" -f2|sed -r 's/^V//;s/([^-]*-g)/r\1/;s/-/./g'
1.9.10.r177.g7bdad49
Oops, resp.:
[rocketmouse@archlinux jack2]$ git describe|sed -r 's/^v//;s/([^-]*-g)/r\1/;s/-/./g'
1.9.10.r177.g7bdad49
The correct dependency seems to be "python2-dbus" and not "python2".
Assumed somebody temporarily wants to build jack2 from git, but switch back to jack2 from the official repository, as soon as 1.9.11 is released, you could replace the original PKGBUILD by this one [1].
To replace .SRCINFO after replacing the PKGBUILD run
makepkg --printsrcinfo > .SRCINFO
Regards,
Ralf
[1]
[rocketmouse@archlinux jack2-rocketmouse]$ cat PKGBUILD
pkgbase=jack2
pkgname=('jack2' 'jack2-dbus')
#pkgname= # single build (overrides split)
_tarname=jack
pkgver=1.9.10.r177.g7bdad49
pkgrel=1
arch=('i686' 'x86_64')
url="http://jackaudio.org/"
backup=(etc/security/limits.d/99-audio.conf)
license=('GPL')
makedepends=('python2-dbus' 'celt' 'opus' 'libsamplerate' 'git' 'libffado')
source=("git+https://github.com/jackaudio/jack2"
'99-audio.conf'
'40-hpet-permissions.rules')
md5sums=('SKIP'
'ae65b7c9ebe0fff6c918ba9d97ae342d'
'471aad533ff56c5d3cbbf65ce32cadef')
_gitname='jack2'
_pyfix() {
sed -i 's:bin/env python:bin/env python2:' \
"$pkgdir/usr/bin/jack_control"
}
_wafconf() {
# default=64, AUR=128, kxstudio=256 --clients=
# default=768, AUR=1536, kxstudio=2048 --ports-per-application=
python2 waf configure --prefix=/usr \
--clients=64 --ports-per-application=768 \
--alsa --firewire $@
}
_isbuild() {
printf "%s\n" ${pkgname[@]} | grep -qx $1
}
pkgver() {
cd jack2
echo $(git describe|cut -d"v" -f2|sed -r 's/^V//;s/([^-]*-g)/r\1/;s/-/./g')
}
prepare() {
# we may do 2 different builds
cp -r $_gitname $_gitname-dbus
}
build() {
cd "$srcdir"
# mixed dbus/classic build
if _isbuild jack2; then
cd $_gitname
msg2 "Running Mixed D-Bus/Classic build"
_wafconf --classic --dbus
python2 waf build $MAKEFLAGS
cd ..
fi
# dbus-ONLY build
if _isbuild jack2-dbus; then
cd $_gitname-dbus
msg2 "Running D-Bus-only build"
_wafconf --dbus
python2 waf build $MAKEFLAGS
cd ..
fi
}
package_jack2() {
! _isbuild jack2 && return 0
pkgdesc="The next-generation JACK with SMP support"
depends=('libsamplerate' 'opus' 'celt' 'libffado')
optdepends=('python2-dbus: jack_control')
conflicts=('jack')
provides=('jack' 'jackmp' 'jackdmp' 'jackdbus')
cd "$srcdir/$_gitname"
python2 waf install --destdir="$pkgdir"
# fix for major python transition
_pyfix
# configure realtime access/scheduling
install -Dm644 "$srcdir/99-audio.conf" \
"$pkgdir/etc/security/limits.d/99-audio.conf"
install -Dm644 "$srcdir/40-hpet-permissions.rules" \
"$pkgdir/usr/lib/udev/rules.d/40-hpet-permissions.rules"
}
package_jack2-dbus() {
! _isbuild jack2-dbus && return 0
pkgdesc="The next-generation JACK with SMP support (for D-BUS interaction only)"
depends=('libsamplerate' 'celt' 'opus' 'libffado')
optdepends=('python2-dbus: jack_control')
conflicts=('jack' 'jack2')
provides=('jack' 'jack2' 'jackmp' 'jackdmp' 'jackdbus')
cd "$srcdir/$_gitname-dbus"
python2 waf install --destdir="$pkgdir"
_pyfix
install -Dm644 "$srcdir/99-audio.conf" \
"$pkgdir/etc/security/limits.d/99-audio.conf"
install -Dm644 "$srcdir/40-hpet-permissions.rules" \
"$pkgdir/usr/lib/udev/rules.d/40-hpet-permissions.rules"
}
Oh silly me :)
On 26.02.2016 11:06, Mathias Buhr wrote:
> Hi Gerald,
>
> I think this was supposed to go to LAU and not me directly :)
>
> Regards,
> Mathias
>
> On 26.02.2016 09:46, Gerald Mwangi wrote:
>> I can recommend Sequent from Loomer
>> (http://www.loomer.co.uk/sequent.htm). While not open source, it is
>> definitely worthwhile using.
>> Gerald / JimsonDrift
>>
>> On 26.02.2016 09:39, Mathias Buhr wrote:
>>> On 02/25/2016 05:01 PM, Johannes Kroll wrote:
>>>> Hi!
>>>>
>>>> I am looking for a repeater/stutter plugin.
Hello Linux Audio Community!
This is the announcement you have been waiting for.
We've come to the conclusion that doing a full LAC at the announced date is
impossible, as our sponsoring setup didn't work out, therefore we have decided
to go ahead with a miniLAC instead.
Since we have already planned a lot of stuff, we thought it would be a shame to
let all the work go to waste, so we asked a few people whether they'd be
interested in a more compact and reduced conference program.
What we can currently offer with the resources available are:
* a lecture track
* workshop tracks (one of which will use the c-base soundlab)
* live audio sessions
* hacking sessions
* tours around interesting berlin places
* linux audio nights
This miniature version of a Linux Audio Conference is still planned to take
place during the (kind of) announced date: 8.-10. April 2016. The location is
now set:
c-base, the spacestation below Berlin Mitte (http://c-base.org)
Our plan is to start off on Friday with a meet-and-greet evening at c-base,
where we will have an open stage for anyone who wants to connect their devices.
Since we don't have the originally intended resources, we will have to limit
attendance to around 150 participants.
Additionally, if there is interest for this (especially for people arriving
earlier), we'll try to organize optional visits to other Berlin locations on
Friday 8. April.
Please create an account on our wiki, to be able to set things up with us:
http://frab.linuxaudio.org (will later move on to
http://minilac.linuxaudio.org).
The wiki is still a work in progress, but should feature all necessary
information by the end of the week.
To satisfy your academic paper skills, we intend to support another crew that
could organize a second conference part at the FrosCon 2016
(http://www.froscon.de/), which is happening in Bonn 20th and 21st of August.
Here is a link to our issue concerning this topic on Github:
https://github.com/linux-audio-berlin/LAC16/issues/30
We hope to see you at the miniLAC16!
Cheers,
miniLAC16 Orga team
On Tue, February 23, 2016 8:32 am, Jonathan Brickman wrote:
> So, if one has a lot of things happening, multiple JACK
> instances could make more use of available resources?
I don't think that follows. That seems to me that you are asking if since
you have a lot of processing going on, would adding additional overhead
help.
If you have multiple processing chains that do not depend on one another,
then using jack2 may help, it can take advantage of multiple processor
cores.
I don't know if that would help with the two yoshimi instances or not, but
since you do not appear to be CPU limited, then probably not.
Real time operation is often more about overhead, the minimum amount of
time it takes for the OS to switch between user mode and kernel mode, the
time it takes the scheduler to determine the next process to run, the
amount of time it takes the kernel to read the current state of the
interrupt controller and call interrupt handlers, things like that. A
lot of those things take fixed amounts of time, so the best thing you can
do for a given system is to try to do them less often, i.e. larger
buffers. For given hardware you may be able to change the system behavior
by modifying firmware settings, like turning off hyperthreading/SMT, or
changing power saving features. Probably those are documented in some
wiki somewhere, but I can't find it on the jackaudio.org wiki at the
moment.
Of course you have to start by making sure that the OS runs the real-time
tasks first, and does not perform general OS housekeeping tasks when there
is real-time work to be done. That is the point of the -RT kernel patches
and to a lesser extent the low-latency config option in the unpatched
kernel tree.
--
Chris Caudle
When I tried to use it sometime ago, puzzling through the docs that came
with it left me just puzzled, without anything convolved. (Sorry, maybe
I'm just stupid.)
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
On Tue, February 23, 2016 11:40 am, Jonathan Brickman wrote:
> and short chain -- IP inputs to zita-njbridge to hardware -- which has
> to be synchronous with the physical audio chipset. So the DSP %
> usage on the hardware-connected chain becomes low, because
> it is as simple as it is, and each of the chains in action have a lot
> less also, distributing the work carefully.
This seems like a pretty complicated scheme. What is your actual end goal?
What do you want to happen differently than your current situation?
Is it just that at 85% DSP usage your system is not capable of running
anything additional, and you want to run additional processes?
If that is all, then first try adjusting the latency of your current setup
to be equivalent to the latency you will have with the Rube Goldberg setup
of a stack of dinky little ARM processors connected together with
resampling through a network.
If you read the zita-njbridge man page you see that the minimum latency is
the sum of the periods of each asynchronous connection, so at minimum
double your current latency, plus resampling latency, plus network delay.
So for a start set your system latency to 2x or 3x what you currently have
and see how that works.
--
Chris Caudle
Eight-core, 4GHz AMD, 8G RAM. Running a lot of things all at once, 60
high-demand tones out of two Yoshimis (120 total), JACK DSP % usage is
85%, but CPU usage through htop is a different thing, one CPU is being
kept by one Yoshimi at 64%, the rest less than 15% and some down to
1-2%. JACK is not stressing any CPU!
So my primary question is, what is JACK DSP % usage, what are its
limiting factors?
--
Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977
Hear us at http://ponderworthy.com -- CDs and MP3 now available!
<http://ponderworthy.com/ad-astra/ad-astra.html>
Music of compassion; fire, and life!!!
