Resending as the first one appears to have been blocked.
On Thu, September 19, 2013 8:46 pm, Fons Adriaensen wrote:
> On Thu, Sep 19, 2013 at 08:04:04PM +1000, Patrick Shirkey wrote:
>
>> > 1. Measure the round-trip latency of your sound card (with an
external analog loop).
>> >
>>
>> Can I use jack_delay running on a second computer connected to the
external i/o of the first computer to get this value?
>
> You'd measure something different...
>
> But you could use two computers as follows:
>
> A = computer with jack, PA, audacity
> B = second computer with sound card, jack and jack_delay.
>
> 1. Measure the round-trip latency on B, with an external
> analog loop.
>
> 2. Connect B -> A, A -> B, run complete chain on A.
>
> 3. Measure again on B, subtract the value from (1).
>
>> > jack_delay -> pa_source -> audacity -> pa_sink -> jack_delay.
>> >
>>
>> Does this look reasonable?
>>
>> 1023.978 frames 21.333 ms total roundtrip latency
>> extra loopback latency: 1023 frames
>> use 511 for the backend arguments -I and -O
>> 1023.976 frames 21.333 ms total roundtrip latency
>> extra loopback latency: 1023 frames
>> use 511 for the backend arguments -I and -O
>> 1023.977 frames 21.333 ms total roundtrip latency
>> extra loopback latency: 1023 frames
>> use 511 for the backend arguments -I and -O
>
> Don't know - I'm by no means a PA expert... and I don't know
> your Jack period size. Given PA's reputation I'd expect more:
> 1024 samples would mean that PA imposes almost the same RT-
> requirements on apps as Jack does, and it was designed *not*
> to do that... But maybe the jack <-> PA interface doesn't
> use the same amount of buffering that PA normally adds.
>
> Note that the value measured is modulo 2^16 samples, but I
> wouldn't expect anything more than a second, so this probably
> irrelevant.
>
Here's a bit more detail for discussion before I send this over to the PA
guys for feedback.
I am seeing the time period returned by jack_delay regularly increase
during the measurement process. Do you have any thoughts on why that would
be happening? I would like to rule out jack_delay because this is most
likely a bug in PA that I have come across now.
I'm using this method:
jack is now set to 64/48000/2
This is the graph:
jack_delay -> pa_source -> audacity -> pa_sink -> jack_delay
Using audacity with 0 internal latency and in pass through mode I see the
following results. It starts out as 10.667ms and after a few seconds it
climbs up to 70.667 ms.
I see similar results with ecasound instead of audacity using the
following graph and ecachain:
jack_delay -> pa_source -> ecasound -> pa_sink -> jack_delay
ecasound -f:32,2,48000 -b:64 -i alsa -o alsa
In that case it starts at 60.000 ms and climbs upto 572.000 ms after a few
seconds of running the test.
Console logs here:
http://boosthardware.com/pa-jack-latency.txt
>
>> > 3. If pa_source and pa_sink are a single Jack client (probably not),
>> > subtract one period from the result of (2).
>>
>> Can you explain that with the data above?
>
> If they are a single Jack client you create a loop in Jack's
> processing graph, this adds one period to the measurement.
>
>
>> > 4. Add the two values.
>> >
>>
>> I would like to provide an app for this task. Do you think it would be
worthwhile to extend jack_iodelay for this purpose?
>
> Don't see how. You need to do two measurements anyway, no matter how
it's done, then add or substract.
>
--
Patrick Shirkey
Boost Hardware Ltd
Moving this thread to LAU as it seems to be a more generic issue now:
I am testing the round trip latency when using PA and JACK together. I
have the following connection graph:
jack_system (in) -> pa_source (in) -> audacity (in) -> audacity (out) ->
pa sink (out) -> jack_system (out)
Audacity is run in pass through mode with internal latency set to 0.
I would like to measure the round trip latency from jack_system (in) to
jack_system (out)
This is a slightly unusual request but it is actually a reasonably
important measurement in the bigger scheme of things.
Does anyone have any suggestions?
Ideally I would like to get accurate measurements for both input and
output latency.
input:
jack_system (in) -> pa_source (in) -> audacity (in)
output:
audacity (out) -> pa sink (out) -> jack_system (out)
So a tool that allowed me to measure the latency between every node on the
graph would be perfect.
Obviously made alot harder by mixing PA and JACK together. I have tried
jack_iodelay but it does not measure the input signal from the mic instead
it provides it's own signal.
I suppose I could modify jack_iodelay to accept an input signal as the
starting point for the latency graph but I have not looked into the code
yet to see how tricky that would be.
--
Patrick Shirkey
Boost Hardware Ltd
Still alive obviously and still using Linux audio exclusively for all studio stuff.
And because I just should, I'll make sure the GF has my correct email for personal biz! lol could be relevant... I have recorded her singing some way cool stuff on Linux too! Currently, Mixbus AND Ardour 3 atop KxStudio an AV Linux!
My what a way we've come!
~ Russell
[sorry, resending this to the list cuz I had forgot the subject]
~~~~~
Thanks Ralf, helpful info. But no luck yet. see below.
> - the nvidia module seems not to be loaded. I guess it's not because I
> > don't see the flash screen NVidia at booting
>
> Don't guess, take a look at /var/log/Xorg.0.log. When doing this, first
> grep EE, IOW run
>
> grep EE /var/log/Xorg.0.log
>
Failed to load module :)
grep EE /var/log/Xorg.0.log
[ 28.292] Current Operating System: Linux blackrottenchest 3.2.48-rt69
#1 SMP PREEMPT RT Wed Sep 11 15:34:00 CEST 2013 i686
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 28.296] Initializing built-in extension MIT-SCREEN-SAVER
[ 30.244] (EE) NVIDIA: Failed to load the NVIDIA kernel module. Please
check your
[ 30.244] (EE) NVIDIA: system's kernel log for additional error
messages.
[ 30.244] (EE) Failed to load module "nvidia" (module-specific error, 0)
[ 30.252] (EE) NVIDIA: Failed to load the NVIDIA kernel module. Please
check your
[ 30.252] (EE) NVIDIA: system's kernel log for additional error
messages.
[ 30.253] (EE) Failed to load module "nvidia" (module-specific error, 0)
[ 30.310] (EE) [drm] KMS not enabled
[ 30.310] (EE) open /dev/dri/card0: No such file or directory
[ 30.334] (EE) open /dev/fb0: No such file or directory
[ 31.077] (EE) Failed to initialize GLX extension (Compatible NVIDIA X
driver not found)
[ 31.149] (II) XKB: reuse xkmfile
/var/lib/xkb/server-3781FECB9CB8D26EE03343DB2C93394EA704B98F.xkm
> > Shall I have run the installer when running the rt-kernel? and if so,
> > why is that, are modules kernel-dependent?
>
> Modules have to fit to the kernel. You should run the NVIDIA *run thingy
> manually.
>
> I've got no time to search for you an English howto, sorry, on the quick
> I only found a German howto:
> http://wiki.ubuntuusers.de/Grafikkarten/Nvidia/Manuelle_Treiberinstallation
>
ok. that clarifies it, thank you.
Anyway, I tried the module building only, and failed again.
to be extra-safe, this time I booted the rt kernel and did:
sudo ./nvidia-installer -a -K --kernel-name=$(uname -r)
>From the nvidia log I can see the module being successfully built, but not
installed because:
ERROR: A DKMS kernel module with version 310.44 is already installed.
ERROR: Installation has failed.
So, something is still wrong. It would seem my previous installation had
installed a module in the rt kernel, but that module doesn't work with rt
kernel 3.2.xx?
thanks,
cheers,
--
Marco Donnarumma
New Media + Sonic Arts Practitioner, Performer, Teacher, Director.
Embodied Audio-Visual Interaction Research Team.
Department of Computing, Goldsmiths University of London
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Portfolio: http://marcodonnarumma.com
Research: http://res.marcodonnarumma.com
Director: http://www.liveperformersmeeting.net
Thanks Ralf, helpful info. But no luck yet. see below.
> - the nvidia module seems not to be loaded. I guess it's not because I
> > don't see the flash screen NVidia at booting
>
> Don't guess, take a look at /var/log/Xorg.0.log. When doing this, first
> grep EE, IOW run
>
> grep EE /var/log/Xorg.0.log
>
Failed to load module :)
grep EE /var/log/Xorg.0.log
[ 28.292] Current Operating System: Linux blackrottenchest 3.2.48-rt69
#1 SMP PREEMPT RT Wed Sep 11 15:34:00 CEST 2013 i686
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 28.296] Initializing built-in extension MIT-SCREEN-SAVER
[ 30.244] (EE) NVIDIA: Failed to load the NVIDIA kernel module. Please
check your
[ 30.244] (EE) NVIDIA: system's kernel log for additional error
messages.
[ 30.244] (EE) Failed to load module "nvidia" (module-specific error, 0)
[ 30.252] (EE) NVIDIA: Failed to load the NVIDIA kernel module. Please
check your
[ 30.252] (EE) NVIDIA: system's kernel log for additional error
messages.
[ 30.253] (EE) Failed to load module "nvidia" (module-specific error, 0)
[ 30.310] (EE) [drm] KMS not enabled
[ 30.310] (EE) open /dev/dri/card0: No such file or directory
[ 30.334] (EE) open /dev/fb0: No such file or directory
[ 31.077] (EE) Failed to initialize GLX extension (Compatible NVIDIA X
driver not found)
[ 31.149] (II) XKB: reuse xkmfile
/var/lib/xkb/server-3781FECB9CB8D26EE03343DB2C93394EA704B98F.xkm
> > Shall I have run the installer when running the rt-kernel? and if so,
> > why is that, are modules kernel-dependent?
>
> Modules have to fit to the kernel. You should run the NVIDIA *run thingy
> manually.
>
> I've got no time to search for you an English howto, sorry, on the quick
> I only found a German howto:
> http://wiki.ubuntuusers.de/Grafikkarten/Nvidia/Manuelle_Treiberinstallation
>
ok. that clarifies it, thank you.
Anyway, I tried the module building only, and failed again.
to be extra-safe, this time I booted the rt kernel and did:
sudo ./nvidia-installer -a -K --kernel-name=$(uname -r)
>From the nvidia log I can see the module being successfully built, but not
installed because:
ERROR: A DKMS kernel module with version 310.44 is already installed.
ERROR: Installation has failed.
So, something is still wrong. It would seem my previous installation had
installed a module in the rt kernel, but that module doesn't work with rt
kernel 3.2.xx?
thanks,
cheers,
--
Marco Donnarumma
New Media + Sonic Arts Practitioner, Performer, Teacher, Director.
Embodied Audio-Visual Interaction Research Team.
Department of Computing, Goldsmiths University of London
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Portfolio: http://marcodonnarumma.com
Research: http://res.marcodonnarumma.com
Director: http://www.liveperformersmeeting.net
Hi, I'd like to compare recording quality of portable recorders.
I only care about the line-in input of these portable recorders.
I'm thinking:
* play audio through a good DAC and feed the line-in of each recorder
* copy audio files off the SD cards from the recorders
* level match the inputs. Probably based on "sox FILE -n stats"
output change input levels on each recorder to match levels.
* play audio again through the DAC and feed the line-ins
* copy audio files off the SD cards from the recorders again
* run something like diff(1) for audio
I'm willing to look at a spectrogram/graph image with feh(1), but I
_really_ don't want to touch a mouse or tab through form
buttons/boxes/inputs on a GUI.
Thanks for reading.
Hello all,
zita-ajbridge-0.4.0 is now available at the usual place:
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html>
>From the README:
* The 'JackPortIsTerminal' and 'JackPortIsPhysical'
flags are set on the Jack ports.
* The correct latency value is set on the Jack ports.
This is the latency resulting from buffering and
resampling. It does not include any additional
latency due to processing by the sound card, e.g.
from anti-alias filters. This can be added using
the -I (for a2j) and -O (for j2a) options, in the
same way as for Jack's ALSA backend.
The README also explains how to test this.
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)
I know this would be like finding a needle in a heystack, but, here goes.
I just recorded an audio track in to ecasound via nama.
Here's the input chain.
Wide diafram condensor mic > Art Tube pack with compressor bipassed >
line 3 of Delta 1010LT > DAW.
There was no processing on the input chanel of the daw.
But, while I was recording an energetic vocal/guitar track, the level
of monitoring output on the mic only dropped about 15-20 db in my
monitoring headphones. The click stayed at normal volume.
Any thoughts at all?
It's pretty hot here in the studio, could the heat be effecting things at all?
CRAZY and mistifyed.
Rusty
> Hi Marco,
>
> I recompiled a real time kernel for 13.04 following the system
> configuration guide (in this case the italian translation that reports
> "3.2.35-rt52").
>
> http://linuxaudio.it/index.php/Configurazione_di_sistemi_audio_GNU/Linux#Co…
>
> I'm using an hp pavilion 6 laptop with the ua-25 ex soundcard and with
> this particular real time Kernel everything works fine.
> 1 xrun discovered at 5,8 ms latency in 3 hours session, recording and
> mixing with Ardour.
>
> Best regards
> Nicola
> >
>
Hi Nicola,
thanks for sharing your experience. The process in that tutorial is very
similar to the one I followed from the other tutorial in English. It's good
to know it works well, yet my problem is with the nvidia driver that needs
to be patched for -rt as well.
thank you!
best,
M