Hi,
Moving this to the LAD list as it seems to be getting to a more technical
and challenging stage now. This may be a simple answer and if so that is
great but suspect it is a bit more complex than that so might require the
brain power of the LAD list rather than just my capabilities.
To recap I am trying to get hard data on the best case latency while
running a combination of JACK + PA. There are various reasons for and
against doing this but discussing them is not the purpose of this thread.
- I am using jack_delay to measure the round trip latency between
jack -> PA -> JACK
- I also have been testing a complete loop including system i/o but for
the purposes of this thread we can ignore those results.
- I have seen some interesting numbers come up today. If I run the
following command:
pactl list sink-inputs
I get numbers similar to this:
Buffer Latency: 8000 usec
Sink Latency: 3166 usec
The combination of the two shows the actual PA Stream Buffer latency
(approx 10 - 11ms). This number stays approximately static while polling
with this command. To be clear there is also the additional latency that
occurs as the data is transferred from PA to the output but I am told it
is negligible although it might turn out to be a key player.
The results from jack_delay are somewhat different. I have included a
snapshot below*.
For reference sake it was also suggested that I open /dev/cpu_dma_latency
and give it a value of 0. /dev/cpu_dma_latency allows to write the latency
you can tolerate (in ms). The kernel will translate this to the deepest
C-state the processor can enter. I have been running my tests with this
value at zero in case it helps. I have checked with powertop and turbostat
but it doesn't appear to make any difference on this machine. Possibly
because it is an older cpu.
Armed with that preliminary information there are a couple of issues that
I am interested in at this juncture.
1: Why PA is reporting 10ms for the stream buffer but jack_delay is giving
the results below.
2: Why PA is reporting 10ms for the stream buffer when I am running jack
at 64 frames/period and ecasound too.
3: Where the fluctuating measurements from jack_delay are coming from in
the graph as PA Stream Buffer is static at 10ms and ecasound is basically
in pass through with a 64/48k buffer same as JACK. A back of the envelop
estimation suggests latency should be stable well under 20ms including the
10ms set aside for the PA Stream buffer.
---------
RESULTS
---------
jack_delay -> pa -> ecasound -> pa -> jack_delay
hda_intel driver
dual core Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz
jack is run at 64/48000/2
ecasound has a period size of 64
PA is configured to run at 48khz too
[*] Here's the snapshot from jack_delay:
62784.000 frames 1308.000 ms total roundtrip latency
extra loopback latency: 62784 frames
use 31392 for the backend arguments -I and -O
62784.000 frames 1308.000 ms total roundtrip latency
extra loopback latency: 62784 frames
use 31392 for the backend arguments -I and -O ?? Inv
63168.000 frames 1316.000 ms total roundtrip latency
extra loopback latency: 63168 frames
use 31584 for the backend arguments -I and -O
63743.999 frames 1328.000 ms total roundtrip latency
extra loopback latency: 63743 frames
use 31871 for the backend arguments -I and -O
64639.999 frames 1346.667 ms total roundtrip latency
extra loopback latency: 64639 frames
use 32319 for the backend arguments -I and -O
64640.000 frames 1346.667 ms total roundtrip latency
extra loopback latency: 64639 frames
use 32319 for the backend arguments -I and -O
64639.999 frames 1346.667 ms total roundtrip latency
extra loopback latency: 64639 frames
use 32319 for the backend arguments -I and -O
64640.000 frames 1346.667 ms total roundtrip latency
extra loopback latency: 64639 frames
use 32319 for the backend arguments -I and -O
64640.000 frames 1346.667 ms total roundtrip latency
extra loopback latency: 64639 frames
use 32319 for the backend arguments -I and -O
64639.999 frames 1346.667 ms total roundtrip latency
extra loopback latency: 64639 frames
use 32319 for the backend arguments -I and -O
64640.000 frames 1346.667 ms total roundtrip latency
extra loopback latency: 64639 frames
use 32319 for the backend arguments -I and -O
64640.000 frames 1346.667 ms total roundtrip latency
extra loopback latency: 64639 frames
use 32319 for the backend arguments -I and -O
64640.000 frames 1346.667 ms total roundtrip latency
extra loopback latency: 64639 frames
use 32319 for the backend arguments -I and -O
65088.000 frames 1356.000 ms total roundtrip latency
extra loopback latency: 65088 frames
use 32544 for the backend arguments -I and -O
65088.000 frames 1356.000 ms total roundtrip latency
extra loopback latency: 65088 frames
use 32544 for the backend arguments -I and -O
65087.999 frames 1356.000 ms total roundtrip latency
extra loopback latency: 65087 frames
use 32543 for the backend arguments -I and -O
65152.000 frames 1357.333 ms total roundtrip latency
extra loopback latency: 65151 frames
use 32575 for the backend arguments -I and -O
65152.000 frames 1357.333 ms total roundtrip latency
extra loopback latency: 65151 frames
use 32575 for the backend arguments -I and -O
65152.000 frames 1357.333 ms total roundtrip latency
extra loopback latency: 65152 frames
use 32576 for the backend arguments -I and -O
65152.000 frames 1357.333 ms total roundtrip latency
extra loopback latency: 65151 frames
use 32575 for the backend arguments -I and -O
65216.000 frames 1358.667 ms total roundtrip latency
extra loopback latency: 65216 frames
use 32608 for the backend arguments -I and -O
64.000 frames 1.333 ms total roundtrip latency
extra loopback latency: 63 frames
use 31 for the backend arguments -I and -O
64.000 frames 1.333 ms total roundtrip latency
extra loopback latency: 63 frames
use 31 for the backend arguments -I and -O ?? Inv
256.000 frames 5.333 ms total roundtrip latency
extra loopback latency: 256 frames
use 128 for the backend arguments -I and -O
256.000 frames 5.333 ms total roundtrip latency
extra loopback latency: 256 frames
use 128 for the backend arguments -I and -O
640.000 frames 13.333 ms total roundtrip latency
extra loopback latency: 640 frames
use 320 for the backend arguments -I and -O
640.000 frames 13.333 ms total roundtrip latency
extra loopback latency: 640 frames
use 320 for the backend arguments -I and -O
640.000 frames 13.333 ms total roundtrip latency
extra loopback latency: 639 frames
use 319 for the backend arguments -I and -O
640.000 frames 13.333 ms total roundtrip latency
extra loopback latency: 640 frames
use 320 for the backend arguments -I and -O
640.000 frames 13.333 ms total roundtrip latency
extra loopback latency: 640 frames
use 320 for the backend arguments -I and -O
640.000 frames 13.333 ms total roundtrip latency
extra loopback latency: 639 frames
use 319 for the backend arguments -I and -O
640.000 frames 13.333 ms total roundtrip latency
extra loopback latency: 639 frames
use 319 for the backend arguments -I and -O
640.000 frames 13.333 ms total roundtrip latency
extra loopback latency: 639 frames
use 319 for the backend arguments -I and -O
640.000 frames 13.333 ms total roundtrip latency
extra loopback latency: 640 frames
use 320 for the backend arguments -I and -O
640.000 frames 13.333 ms total roundtrip latency
extra loopback latency: 640 frames
use 320 for the backend arguments -I and -O
768.001 frames 16.000 ms total roundtrip latency
extra loopback latency: 768 frames
use 384 for the backend arguments -I and -O
832.000 frames 17.333 ms total roundtrip latency
extra loopback latency: 832 frames
use 416 for the backend arguments -I and -O
832.000 frames 17.333 ms total roundtrip latency
extra loopback latency: 832 frames
use 416 for the backend arguments -I and -O
832.000 frames 17.333 ms total roundtrip latency
extra loopback latency: 831 frames
use 415 for the backend arguments -I and -O
832.000 frames 17.333 ms total roundtrip latency
extra loopback latency: 832 frames
use 416 for the backend arguments -I and -O
1024.000 frames 21.333 ms total roundtrip latency
extra loopback latency: 1024 frames
use 512 for the backend arguments -I and -O ??
1024.000 frames 21.333 ms total roundtrip latency
extra loopback latency: 1024 frames
use 512 for the backend arguments -I and -O
1024.000 frames 21.333 ms total roundtrip latency
extra loopback latency: 1023 frames
use 511 for the backend arguments -I and -O
1024.000 frames 21.333 ms total roundtrip latency
extra loopback latency: 1023 frames
use 511 for the backend arguments -I and -O
1344.000 frames 28.000 ms total roundtrip latency
extra loopback latency: 1344 frames
use 672 for the backend arguments -I and -O
--
Patrick Shirkey
Boost Hardware Ltd
Hi Hermann
I've been trying to build the latest versions of Guitarix - both the git
latest version (29 I believe) as the 28-2 - and both yield the same error
when I try to use the -optimization flag
package libcloog-ppl0 not found : optimization is disabled
I'm using an Arch Linux on an Intel Atom N2800 and I have the AUR cloog-ppl
0.16.1-1 package installed.
Is there something else to be done in order to get the optimization flag to
work? Iǘe browsed the LAD archives and noticed there is already a tread
with this error in topic for version 27.
Can I discard the optimization flag and add the "march=native" instead? If
yes, how should I do it?
Can't wait to try the gx-fuzz on the MOD!
Kind regards and congratulations for the effort on Guitarix. Here at the
MOD Team we have it as on of our favourite plugins pack.
Gianfranco
Hi all,
tomorrow it is time again for Creative Music Coding at STEIM, please
join us!
First episode of the new season!
Calling all ChucK’ers, SuperColliders, Max and PureData patchers,
CSounders, Fluxites, Overtoners, and all other tongues of creative
coders. We welcome you to attend the fifth edition of the Creative
Music Coding lab at STEIM.
The CMC lab is an autonomous zone to try out sonic experiments as a
group. And an opportunity to leverage the expertise of the group in
realizing new artistic tools and processes through the medium of code.
Many of the founding members of the group are indeed experts in their
favorite languages, but we come from all technical levels of
proficiency and enjoy helping one-another out.
http://steim.org/event/creative-music-coding-lab-6/
Date: Tuesday, October 1st
Time: 19:00 h
Venue: Steim, Utrechtsedwarsstraat 134, Amsterdam
Entry: Free
There will be free coffee and tea to fuel the creativity.
Let me know if you plan to attend!
sincerely,
Marije
As some of you may recall, every time I've posted a demo video to LAD, I've
had to include a disclaimer excusing the poor quality due to a lack of
functional screencasting tools.
Well, it took a couple of weeks of hair pulling and many, many hours of
testing, but I finally arrived at a solution.
Anyone who wants to create a screencast and record audio via JACK *in
perfect sync* must do the following:
Get ffmpeg. Apply this patch to it:
https://github.com/original-male/FFmpeg/commit/d02509d04d396a98646ca81e9ba3…
Build it with vorbis and h264 support.
Then, start your favorite desktop environment. I use Xephyr for this.
Have jack running (at -r 48000)
Then run the following command:
ffmpeg -fflags +genpts+igndts -f x11grab -vsync 0 -r 30 -s 1920x1080 -i
:${DISPLAY}.+0,0 -vcodec h264 -f jack -ac 2 -r:a 48000 -i screencast
-acodec pcm_s16le -r:v 30 -vsync 2 -async 1 -map 0:0,1,0 -map 1:0 -preset
ultrafast -qp 0 "$FILE"
Where DISPLAY is the number of your X11 display and FILE is the filename
for the screencast. I use a .mkv extension for the matroska container.
Remember to connect the streams you want recorded to the 'screencast' JACK
inputs!
With this setup I'm able to record a full 30 FPS @ 1080P with audio in
perfect sync. Please share your results too. With some more evidence I
might have a good case to get ffmpeg to accept my patch.
Enjoy!
Hi there,
Apologies for cross-posting.
We're looking for a Linux embedded coder, preferably in London, for a
short-term optimisation gig on an ARM 8. To start immediately. Salary
depending on experience / delivery.
http://weareroli.com
Let me know if you're interested!
Goal:
- Optimisation of C++ code to match the target accelerator engine NEON
- Development of a custom shared DSP library based on the NEON instruction
set
Skills:
- Excellent understanding of the low level ARM architecture (Vector
floating point unit, SIMD, NEON)
- High proficiency with C/C++, ASM, Unit Testing
- Experience in audio DSP algorithm embedded integration
- High efficiency audio coding experience
- Excellent knowledge of the standard tools such as gcc, gbd
Best regards,
Jean-Baptiste
Am Dienstag, den 24.09.2013, 20:11 +0200 schrieb Ralf Mardorf:
> Hi :)
>
> I used the new tar, but next time I can checkout from svn.
>
> It failed to build again.
>
> checking for XMLRPC... no
> configure: error: Package requirements (xmlrpc >= 1.32.5) were not met:
>
> No package 'xmlrpc' found
>
> Consider adjusting the PKG_CONFIG_PATH environment variable if you
> installed software in a non-standard prefix.
>
> Alternatively, you may set the environment variables XMLRPC_CFLAGS
> and XMLRPC_LIBS to avoid the need to call pkg-config.
> See the pkg-config man page for more details.
> [rocketmouse@archlinux ags_0.3.99]$ sudo pacman -Q xmlrpc-c
> xmlrpc-c 1:1.33.03-1
>
> Regards,
> Ralf
>
https://apps.fedoraproject.org/packages/xmlrpc-c-client
alien the package if using debian or derivates.
Is without xmlrpc but has missing bugfixes ...
https://github.com/weedlight/ags/tree/master/0.4.0/src/ags
I'll update github.com repo excluding xmlrpc.
The server isn't started by default and is only a collection of ideas
whereas many skelletons for a XML based scripting client. See for
further details:
https://sourceforge.net/p/ags/code/HEAD/tree/src/ags-client/scripting/ags_s…
regards
Joël
Hi, I'm writing a software synth/sequencer called Advanced Gtk+
Sequencer. It won't take much time till first pre-release 0.4.0 I got
basic functions working. Now I'm pleased to ask if someone wants to
contribute. Note pulseaudio interferes with Advanced Gtk+ Sequencer to
achieve best results I even recommend WindowMaker as desktop or any
minimal window manager of your choice.
http://sourceforge.net/projects/ags/
If your asking yourself how to use Advanced Gtk+ Sequencer please take a
look at a screencast I just made this morning on Google+
The project features a wiki with some programming howtos and explanation
of internals.
bye
Joël
Behold the beauty of FOSS !
(A fine example of how it can also be done)
Op 20-sep.-2013 23:46 schreef "Arnold Krille" <arnold(a)arnoldarts.de> het
volgende:
On Fri, 20 Sep 2013 12:45:45 +0100 Dr Nicholas J Bailey
<nicholas.bailey(a)glasgow.ac.uk> wrote:
> Ha, it seems I submitted news about a fork right into a firestorm!
>
> Well, I've done it, take it or leave it.
>
> For the record, I did email Arnold Krille several times without
> getting a reply, which is fine because there isn't a law which says
> he has to answer emails from me.
Mostly due to the fact that I don't answer when there is no time. And
then tend to forget these mails when they drop below the fold...
> Also, the (C) on that software says
> -2007, so I went ahead. It probably wasn't a good time in retrospect.
It was at the best of times! And its not the first fork of JackMix,
but probably the first on github...
> I didn't intend to upset Arnold or anybody else, but the only way I'm
> taking my "fork" off github is if Arnold thinks it's good enough to
> make it mainstream, which would be an honour and a privilege.
The main concern for me is that (if I understand git correctly) its now
not possible for me to import my private subversion history of JackMix
into github and then officially mark yours as the fork... As my vcs was
private all the past time, thats not a big concern.
You could also have given your project a new name. Which is hard when
the good names are all taken...
But seeing as I don't really have time for audio-programming since
quite some years, please continue!
> I still really hope Arnold is going to let me ask him some
> questions about his code!
I don't know if I can answer your questions. As you rightly noticed,
its been some time since I wrote that code.
I would write it differently today (test-driven, gui in python and only
the mixing-engine in C++). I kind of started parts for a rewrite,
there's a mixing-matrix-gui in ffado-mixer thats similar and I have
some local beginnings of a crossbar-router for jack (patchage with rows
and cols instead of a free canvas) with network-transparent separation
of gui and core. But that never really hit of with me due to a lack of
time and need...
Anyway, please remind me to look at your project, create a nice page on
github for it and remind me to set a link to that page on my domain.
I hereby proclaim you the new lead for JackMix!
Have fun,
Arnold
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
I agree with Nils 100%. Fons mentions the second fork seems to be changing the license. Both situations are ignorant of the spirit of FOSS in my opinion.
If you go commercial let me know. I'll buy everything you make !
g
Sent from my smartphone.Â
-------- Original message --------
From: Fons Adriaensen <fons(a)linuxaudio.org>
Date: 19/09/2013 7:16 AM (GMT+10:00)
To: Linux Audio Users <linux-audio-user(a)lists.linuxaudio.org>,Linux Audio Developers <linux-audio-dev(a)lists.linuxaudio.org>
Subject: [LAD] Aeolus
Hello all,
It has come to my attention that there are ATM at least two
'forks' of Aeolus. The first by the MuseScore team, the second
by one Maurizio Gavioli.
Neither of them even had the decency to let me know of their
work, and both are taking Aeolus in a direction I do not
approve of. Gavioli has even added his 'copyright' to the
sources of the libraries that Aeolus depends on but which
are not part of its source distribution. Apparently the
intention is to release incompatible versions of those as
well.
If this is typical for the attitude taken by the Linux Audio
community then my motivation to contribute to it will take
a serious blow.
As announced previously, there will be a fully reworked
release of Aeolus next year (on the occasion of its 10th
birthday). Apart from major improvements to the audio code
it will be completely OSC controlled. None of this will be
compatible with the forks of course, they'll find themselves
instantly obsolete. And I will make sure that this sort of
thing won't happen again, even if that means a more restrictive
license.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev