6 Apr
2006
6 Apr
'06
8:36 a.m.
Hello!
I'm planning to get RME Multiface (II) and have a question to it's owners.
Can you, please, post its latency in audio loop, measured with jaaa in
2x64 buffer setup.
Thank you.
Regards,
Dmitry.
P.S. crossposted from LAU, since there were no responces.
6 Apr
6 Apr
9:42 a.m.
On Thu, Apr 06, 2006 at 02:36:34PM +0400, Dmitry Baikov wrote:
Hello!
I'm planning to get RME Multiface (II) and have a question to it's owners.
Can you, please, post its latency in audio loop, measured with jaaa in
2x64 buffer setup.
Better use jdelay for that, that's why it exists !
--
FA
Follie! Follie! Delirio vano e' questo!
12:41 p.m.
On Thu, Apr 06, 2006 at 04:50:37PM +0400, Dmitry Baikov wrote:
It shouldn't take more than a minute...
--
FA
Follie! Follie! Delirio vano e' questo!
Better use
jdelay for that, that's why it exists !
Oops, my bad - I mixed up the names...
P.S. that's why I get no responces - they are still measuring.... 
3:51 p.m.
"Dmitry Baikov" <dsbaikov(a)gmail.com>om>:
> > P.S. that's why I get no responces -
they are still
> > measuring....
Might be because there are no Multiface II's around. Anyway,
here are numbers for a hdsp 9652 + Behringer ada8000 audio
loop, the hdsp has similar core specs down to the FPGA
architecture.
jackd with -p 64 -n 2
jdelay -> pcm_playback -> ada8000 -> pcm_capture -> jdelay
makes jdelay say 195.440 frames which is good for
2 x 64 frames jack latency
+ 2 x 33.72 frames non-jack latency (in part hdsp's handling,
in part the ada8000's handling)
Can't take the ada8000 out of the picture because the hdsp has
no analog inputs, same "problem" with a digiface, I guess.
I'd appreciate the same measurement from a multiface owner.
--
Wolfgang
6:44 p.m.
Thank you for the answers.
On 4/6/06, Wolfgang Woehl <tito(a)rumford.de> wrote:
Might be because there are no Multiface II's
around.
My bad again, too strict specification ;)
I'm sure Multiface II has nearly the same values as an original Multiface.
They differs in analog part mostly and has different DACs/ADCs
(possibly meaning different amout of buffering).
6:51 p.m.
My Delta66 has latency of 188 samples.
In theory, Multiface's could have the same results, but it definetely
should do more buffering to send values to breakout box.
As Jan measured, there is a little: ~207 vs 188.
Thank you!
Dmitry.
P.S. if only EMU 1616M had linux drivers...
At least RME has much better quality for its price, I hope.
4:28 p.m.
Hi Dmitry,
Am Donnerstag, den 06.04.2006, 14:36 +0400 schrieb Dmitry Baikov:
I'm planning to get RME Multiface (II) and have a
question to it's owners.
Can you, please, post its latency in audio loop, measured with jaaa in
2x64 buffer setup.
206.805
This is a Thinkpad T43 with an unpatched 2.6.16 with CONFIG_PREEMPT=y,
jackd 0.100.7, 2x64@48000.
Now what does that value tell me? These are samples, I suppose, i. e.
4.308 msec? Fons, how do you think about a little accompanying
README? :)
Jan
4:45 p.m.
On Thu, Apr 06, 2006 at 08:28:32PM +0200, Jan Weil wrote:
206.805
This is a Thinkpad T43 with an unpatched 2.6.16 with CONFIG_PREEMPT=y,
jackd 0.100.7, 2x64@48000.
Now what does that value tell me? These are samples, I suppose, i. e.
4.308 msec?
Yep, it's samples.
Fons, how do you think about a little accompanying
README? :)
Good idea :-) This was written and released in a hurry...
Or maby I should just add 'frames' to the printed value.
Have you been able to use -p 64 with 2.6.16 on the Thinkpad with ACPI ?
I had no problems with it on my R51 when using 2.6.8 (SuSE 9.2), but
since 2.6.13 (SuSE 10.0) I have to disable it. Killing the modules doesn't
help, but acpi=off on the kernel command line does. Same with 2.6.15-rt.
APM doesn't seem to do any harm, so that's what I use now. I wonder if
the new dbus things are causing this.
--
FA
Follie! Follie! Delirio vano e' questo!
4:57 p.m.
On Thu, 2006-04-06 at 20:52 +0200, fons adriaensen wrote:
Have you been able to use -p 64 with 2.6.16 on the
Thinkpad with
ACPI ? I had no problems with it on my R51 when using 2.6.8 (SuSE
9.2), but since 2.6.13 (SuSE 10.0) I have to disable it. Killing the
modules doesn't help, but acpi=off on the kernel command line does.
Same with 2.6.15-rt. APM doesn't seem to do any harm, so that's what I
use now. I wonder if the new dbus things are causing this.
I doubt it's related to dbus, it sounds more like an ACPI kernel bug was
introduced.
How exactly does it fail?
Lee
5:18 p.m.
On Thu, Apr 06, 2006 at 02:57:28PM -0400, Lee Revell wrote:
On Thu, 2006-04-06 at 20:52 +0200, fons adriaensen
wrote:
Every 40 seconds I get a shower of timeouts in JACK, even when no clients
are running. I suspected the battery check of course, but that is configured
for a 60 second period, and it didn't do any harm before. Killing powersaved
and friends doesn't help, so indeed it looks like a kernel bug.
BTW, I noticed your talk in the LAC2006 program just a few minutes ago.
Looking forward to see you there !
--
FA
Follie! Follie! Delirio vano e' questo!
Have you been able to use -p 64 with 2.6.16 on
the Thinkpad with
ACPI ? I had no problems with it on my R51 when using 2.6.8 (SuSE
9.2), but since 2.6.13 (SuSE 10.0) I have to disable it. Killing the
modules doesn't help, but acpi=off on the kernel command line does.
Same with 2.6.15-rt. APM doesn't seem to do any harm, so that's what I
use now. I wonder if the new dbus things are causing this.
I doubt it's related to dbus, it sounds more like an ACPI kernel bug was
introduced.
How exactly does it fail?
5:31 p.m.
On Thu, 2006-04-06 at 21:25 +0200, fons adriaensen wrote:
Every 40 seconds I get a shower of timeouts in JACK,
even when no clients
are running. I suspected the battery check of course, but that is configured
for a 60 second period, and it didn't do any harm before. Killing powersaved
and friends doesn't help, so indeed it looks like a kernel bug.
If you really want to solve this and are sure it broke between 2.6.12
and 2.6.13 you could do a git bisect to find the problem. If all you
know is it broke between 2.6.8 and 2.6.13 - ugh ;-)
BTW, I noticed your talk in the LAC2006 program just a
few minutes
ago. Looking forward to see you there !
Yep, looking forward to it myself!
Lee
7 Apr
7 Apr
6:44 a.m.
Am Donnerstag, den 06.04.2006, 20:52 +0200 schrieb fons adriaensen:
On Thu, Apr 06, 2006 at 08:28:32PM +0200, Jan Weil
wrote:
Well, now that it's found its way to the LAD archives... just for the
sake of googleability I'll add that we're talking about jdelay here
which is used to measure the latency of your sound card.
206.805
This is a Thinkpad T43 with an unpatched 2.6.16 with CONFIG_PREEMPT=y,
jackd 0.100.7, 2x64@48000.
Now what does that value tell me? These are samples, I suppose, i. e.
4.308 msec?
Yep, it's samples.
Fons, how do you think about a little
accompanying README? :)
Good idea :-) This was written and released in a hurry...
Or maby I should just add 'frames' to the printed value.
6:48 a.m.
New subject: [linux-audio-dev] debugging xruns
Am Donnerstag, den 06.04.2006, 20:52 +0200 schrieb fons adriaensen:
On Thu, Apr 06, 2006 at 08:28:32PM +0200, Jan Weil
wrote:
> This is a Thinkpad T43 with an unpatched 2.6.16 with CONFIG_PREEMPT=y,
> jackd 0.100.7, 2x64@48000.
Have you been able to use -p 64 with 2.6.16 on the
Thinkpad with ACPI ?
I had no problems with it on my R51 when using 2.6.8 (SuSE 9.2), but
since 2.6.13 (SuSE 10.0) I have to disable it. Killing the modules doesn't
help, but acpi=off on the kernel command line does. Same with 2.6.15-rt.
APM doesn't seem to do any harm, so that's what I use now. I wonder if
the new dbus things are causing this.
Yes, ACPI is enabled and running ardour the system is rock solid, no
xruns at all (which is great!). I still have problems running other
apps, though, e. g. freewheeling. After a couple of minutes xruns start
occuring on a regular basis. Disabling ACPI didn't help, neither did
-rt10. Unfortunately, I suspect these xruns being caused by the hdsp
module sharing its interrupt with several others including eth0 and ATIs
binary-only fglrx which I'm currently forced to use because xorg refuses
to start otherwise. Additionally, -rt10 somehow made my system appear
slugghish, e. g. booting takes significantly longer. I guess that's not
what it's supposed to do. I'm still tweaking the whole system. Maybe Lee
& Co. can lead me through the debugging process. How can I find out what
causes these xruns? [And yes, I'm trying hard to get rid of fglrx. ;-)]
Jan
12 Apr
12 Apr
3:57 p.m.
"Dmitry Baikov" <dsbaikov(a)gmail.com> writes:
post its latency (2x64)
..and I suppose you mean 48000 sampling rate.
I get:
206.765
Actually, it varies between 206.765 and 206.766
FUJITSU SIEMENS D1561
Intel(R) Celeron(R) CPU 2.40GHz
linux-2.6.16
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
[sip|iax]: e e
jid:b0ef@ n n
8:30 p.m.
On 4/12/06, Esben Stien <b0ef(a)esben-stien.name> wrote:
I'm sure it does not matter, jdelay measures samples not seconds.
Or hw can have different paths for different sample rates?
post its
latency (2x64)
..and I suppose you mean 48000 sampling rate. 206.765
Thanks.
Dmitry.
6598
days inactive
6604
days old
linux-audio-dev@lists.linuxaudio.org
17 comments
7 participants
participants (7)
-
Alfons Adriaensen -
Dmitry Baikov -
Esben Stien -
fons adriaensen -
Jan Weil -
Lee Revell -
Wolfgang Woehl