jamin-devel

[Jamin] ardour export + jamin

[Kees v. V. <kee...@gm...>]

Hi,

I've joined the mailing list because of topic 
http://ardour.org/node/3016 concerning Ardour export with Jamin as an 
insert on the master bus, which (on all Ubuntu versions I've tried: 
Hardy, Jaunty and Karmic) causes Jamin to abort mostly at the very end 
of the export. I have no problem with running Jamin as an insert in 
'normal' mode.

When debugging I found that the condition upon a Jack ringbuffer write 
of io_queue() in io.c, causes Jamin to panic and abort() when the number 
of bytes to write does not correspond to the bytes written.

I am not familiar with audio programming, so I maybe completely off 
track, but I wondered why Jamin doesn't do a retry. For normal operation 
(as I gather from the comment before the abort()) that would probably 
not be a good idea, but when Ardour exports it goes into freewheeling 
mode, and I gather that in that case 'different rules' apply, i.e. Jack 
tries to run as fast as it can, but it waits for children to complete 
their task, if I'm phrasing that correctly.

I fiddled around with retrying to write the remaining bytes to the ring 
buffer (in freewheeling mode), and from the several times I've tried it, 
it seems to work properly, i.e. Jamin does not abort and eventually 
succeeds in writing all the bytes to the ring buffer, without (to me) 
audible effects in the export. I've attached the io.c diff to the latest 
CVS tree.

 From the Ardour forum I was told that I could get away with it, but I 
was solving the problem by the wrong means, which very well may be true.

This problem seems to have been around for quite some time, and keeps 
being reported. Would be nice to get that fixed.

Could any of you comment or help me in the right direction ?

Regards,
Kees

Re: [Jamin] ardour export + jamin

[Kees v. V. <kee...@gm...>]

Hi Jack,

Thanks for the quick reply and instructions. I'll try to do that later 
tonight.

My .jackrc contains: /usr/bin/jackd -R -dalsa -dhw:0 -r44100 -p64 -n4. 
So indeed 64. I minimized that to get a minimum latency without xruns 
(but without thinking about it).

I did some stderr logs of the cnt that the ring buffer write did and the 
nbytes, and most of the time it was 1 byte short, so cnt=255 and nbytes=256.

Thanks,
Kees

-------- Original Message --------
Subject: Re: [Jamin] ardour export + jamin
From: Jack O'Quin <jac...@gm...>
To: Kees van Veen <kee...@gm...>
Date: Wed Jan 13 2010 17:53:55 GMT+0100 (CET)
> On Wed, Jan 13, 2010 at 10:32 AM, Jack O'Quin <jac...@gm...> wrote:
>   
>> On Wed, Jan 13, 2010 at 2:40 AM, Kees van Veen <kee...@gm...> wrote:
>>     
>
>   
>> If you can reproduce this error, please configure your system to take
>> a core dump (ulimit -c unlimited), trigger the failure, then print the
>> gdb stack traceback for all the jamin threads:
>>
>> gdb> thread all apply bt
>>
>> Then, please send the output to this list, along with your JACK
>> parameters (period, etc) and any other interesting facts you can think
>> of.
>>     
>
> Kees,
>
> I just read the long thread about this from the Ardour site.  The
> process thread aborts exactly where I expected from your description.
> But, I'd still like to know where the other threads were at that time.
>
> Is your JACK period less than 256 frames?  What happens if you use a
> larger frame size (at least 256)?  Does the problem go away then?
>
> Depending on what we discover, I may ask you to try some different patches.
>
> Regards,
>   

Re: [Jamin] ardour export + jamin

[Kees v. V. <kee...@gm...>]

Jack,

Can't get it to abort when the Jack period is 256. Tried it several 
times without aborting. My .jackdrc then was: /usr/bin/jackd -R -dalsa 
-dhw:0 -r44100 -p256 -n2

As soon as I changed my jack settings to 64 frames: /usr/bin/jackd -R 
-dalsa -dhw:0 -r44100 -p64 -n4, Jamin aborted at the end of the first 
export I tried.

I've attached the gdb.log with the content you asked. Kernel: Linux 
2.6.31-9-rt #152-Ubuntu SMP PREEMPT RT Thu Oct 15 05:01:14 UTC 2009 i686 
GNU/Linux. All packages from the Ubuntu Karmic standard repos.

Changing the jack settings to 128 frames: /usr/bin/jackd -R -dalsa 
-dhw:0 -r44100 -p128 -n2, did not show the abort either, tried it 
several times in a row.

As soon as I changed it back to 64 as above, trouble started again.

I'm very curious about the magical 256/128 ...

If you need more info, or want me to try other things, let me know.

Regards,
Kees

-------- Original Message --------
Subject: Re: [Jamin] ardour export + jamin
From: Jack O'Quin <jac...@gm...>
To: Kees van Veen <kee...@gm...>
Date: Wed Jan 13 2010 17:53:55 GMT+0100 (CET)
> On Wed, Jan 13, 2010 at 10:32 AM, Jack O'Quin <jac...@gm...> wrote:
>   
>> On Wed, Jan 13, 2010 at 2:40 AM, Kees van Veen <kee...@gm...> wrote:
>>     
>
>   
>> If you can reproduce this error, please configure your system to take
>> a core dump (ulimit -c unlimited), trigger the failure, then print the
>> gdb stack traceback for all the jamin threads:
>>
>> gdb> thread all apply bt
>>
>> Then, please send the output to this list, along with your JACK
>> parameters (period, etc) and any other interesting facts you can think
>> of.
>>     
>
> Kees,
>
> I just read the long thread about this from the Ardour site.  The
> process thread aborts exactly where I expected from your description.
> But, I'd still like to know where the other threads were at that time.
>
> Is your JACK period less than 256 frames?  What happens if you use a
> larger frame size (at least 256)?  Does the problem go away then?
>
> Depending on what we discover, I may ask you to try some different patches.
>
> Regards,
>   

Re: [Jamin] ardour export + jamin

[Jan D. <evi...@ca...>]

On Wed, 2010-01-13 at 21:51 +0100, Kees van Veen wrote:
> Jack,
> 
> Can't get it to abort when the Jack period is 256. Tried it several 
> times without aborting. My .jackdrc then was: /usr/bin/jackd -R -dalsa 
> -dhw:0 -r44100 -p256 -n2
> 
> As soon as I changed my jack settings to 64 frames: /usr/bin/jackd -R 
> -dalsa -dhw:0 -r44100 -p64 -n4, Jamin aborted at the end of the first 
> export I tried.
> 
> I've attached the gdb.log with the content you asked. Kernel: Linux 
> 2.6.31-9-rt #152-Ubuntu SMP PREEMPT RT Thu Oct 15 05:01:14 UTC 2009 i686 
> GNU/Linux. All packages from the Ubuntu Karmic standard repos.
> 
> Changing the jack settings to 128 frames: /usr/bin/jackd -R -dalsa 
> -dhw:0 -r44100 -p128 -n2, did not show the abort either, tried it 
> several times in a row.
> 
> As soon as I changed it back to 64 as above, trouble started again.
> 
> I'm very curious about the magical 256/128 ...
> 

    There seems to be a lot of misunderstanding about when you need low
latency.  If you're not running live or trying to record new tracks
while using software monitoring you don't really need low latency.
JAMin wasn't designed for live work and it wasn't designed to be a
plugin for a single track.  It was designed for stereo audio mastering.
The amount of processing involved is significant so it probably won't be
able to keep up with small period sizes.  Just kick it up to 2048 and
relax ;-)


> If you need more info, or want me to try other things, let me know.
> 
> Regards,
> Kees
> 
> -------- Original Message --------
> Subject: Re: [Jamin] ardour export + jamin
> From: Jack O'Quin <jac...@gm...>
> To: Kees van Veen <kee...@gm...>
> Date: Wed Jan 13 2010 17:53:55 GMT+0100 (CET)
> > On Wed, Jan 13, 2010 at 10:32 AM, Jack O'Quin <jac...@gm...> wrote:
> >   
> >> On Wed, Jan 13, 2010 at 2:40 AM, Kees van Veen <kee...@gm...> wrote:
> >>     
> >
> >   
> >> If you can reproduce this error, please configure your system to take
> >> a core dump (ulimit -c unlimited), trigger the failure, then print the
> >> gdb stack traceback for all the jamin threads:
> >>
> >> gdb> thread all apply bt
> >>
> >> Then, please send the output to this list, along with your JACK
> >> parameters (period, etc) and any other interesting facts you can think
> >> of.
> >>     
> >
> > Kees,
> >
> > I just read the long thread about this from the Ardour site.  The
> > process thread aborts exactly where I expected from your description.
> > But, I'd still like to know where the other threads were at that time.
> >
> > Is your JACK period less than 256 frames?  What happens if you use a
> > larger frame size (at least 256)?  Does the problem go away then?
> >
> > Depending on what we discover, I may ask you to try some different patches.
> >
> > Regards,
> >   
> 
> 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________ Jamin-devel mailing list Jam...@li... https://lists.sourceforge.net/lists/listinfo/jamin-devel

Re: [Jamin] ardour export + jamin

[Kees v. V. <kee...@gm...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Jack,<br>
<br>
I tried running Jamin from the Ubuntu repos (not even in debug, but
stripped) with the -T flag and jack -p64 -n4, which aborted, but no
file, no stderr output (as I gather -T flag should provide). Remake in
debug made no difference.<br>
<br>
Then I tried the latest CVS tree, ./configure without options, make,
make install.<br>
(At first it wouldn't abort, tried it several times, but then I
discovered my patched io.c was still in the tree <span
 class="moz-smiley-s6"><span> :-[ </span></span>, removed it, cvs
update, cvs diff, make, make install, then it aborted).<br>
<blockquote><tt>$ /usr/local/bin/jamin -p -T<br>
jamin 0.97.14<br>
(C) 2003-2005 J. Depner, S. Harris, J. O'Quin, R. Parker and P. Shirkey<br>
This is free software, and you are welcome to redistribute it<br>
under certain conditions; see the file COPYING for details.<br>
Cannot find plugin 'sc4_1882.so'<br>
Required plugin sc4_1882.so missing.<br>
Please load the SWH plugins.<br>
$ export LADSPA_PATH=/usr/lib/ladspa/<br>
$ /usr/local/bin/jamin -p -T<br>
jamin 0.97.14<br>
(C) 2003-2005 J. Depner, S. Harris, J. O'Quin, R. Parker and P. Shirkey<br>
This is free software, and you are welcome to redistribute it<br>
under certain conditions; see the file COPYING for details.<br>
Cannot find plugin 'foo_limiter.so'<br>
  <br>
(jamin:24320): Gtk-WARNING **: GtkSpinButton: setting an adjustment
with non-zero page size is deprecated<br>
  <br>
(jamin:24320): Gtk-WARNING **: GtkSpinButton: setting an adjustment
with non-zero page size is deprecated<br>
  <br>
(jamin:24320): Gtk-WARNING **: GtkSpinButton: setting an adjustment
with non-zero page size is deprecated<br>
  <br>
(jamin:24320): Gtk-WARNING **: GtkSpinButton: setting an adjustment
with non-zero page size is deprecated<br>
  <br>
(jamin:24320): Gtk-WARNING **: GtkSpinButton: setting an adjustment
with non-zero page size is deprecated<br>
  <br>
(jamin:24320): Gtk-WARNING **: GtkSpinButton: setting an adjustment
with non-zero page size is deprecated<br>
  <br>
(jamin:24320): Gtk-WARNING **: GtkSpinButton: setting an adjustment
with non-zero page size is deprecated<br>
  <br>
(jamin:24320): Gtk-WARNING **: GtkSpinButton: setting an adjustment
with non-zero page size is deprecated<br>
Started OSC server thread at osc.udp://cvn:4444/<br>
Aborted<br>
$ gdb /usr/local/bin/jamin<br>
GNU gdb (GDB) 7.0-ubuntu<br>
Copyright (C) 2009 Free Software Foundation, Inc.<br>
License GPLv3+: GNU GPL version 3 or later
<a class="moz-txt-link-rfc2396E" href="http://gnu.org/licenses/gpl.html">&lt;http://gnu.org/licenses/gpl.html&gt;</a><br>
This is free software: you are free to change and redistribute it.<br>
There is NO WARRANTY, to the extent permitted by law.&nbsp; Type "show
copying"<br>
and "show warranty" for details.<br>
This GDB was configured as "i486-linux-gnu".<br>
For bug reporting instructions, please see:<br>
<a class="moz-txt-link-rfc2396E" href="http://www.gnu.org/software/gdb/bugs/">&lt;http://www.gnu.org/software/gdb/bugs/&gt;</a>...<br>
Reading symbols from /usr/local/bin/jamin...done.<br>
(gdb) r -p -T<br>
Starting program: /usr/local/bin/jamin -p -T<br>
[Thread debugging using libthread_db enabled]<br>
jamin 0.97.14<br>
(C) 2003-2005 J. Depner, S. Harris, J. O'Quin, R. Parker and P. Shirkey<br>
This is free software, and you are welcome to redistribute it<br>
under certain conditions; see the file COPYING for details.<br>
[New Thread 0xb7ea8b70 (LWP 25039)]<br>
Cannot find plugin 'foo_limiter.so'<br>
  <br>
(jamin:25035): Gtk-WARNING **: GtkSpinButton: setting an adjustment
with non-zero page size is deprecated<br>
  <br>
(jamin:25035): Gtk-WARNING **: GtkSpinButton: setting an adjustment
with non-zero page size is deprecated<br>
  <br>
(jamin:25035): Gtk-WARNING **: GtkSpinButton: setting an adjustment
with non-zero page size is deprecated<br>
  <br>
(jamin:25035): Gtk-WARNING **: GtkSpinButton: setting an adjustment
with non-zero page size is deprecated<br>
  <br>
(jamin:25035): Gtk-WARNING **: GtkSpinButton: setting an adjustment
with non-zero page size is deprecated<br>
  <br>
(jamin:25035): Gtk-WARNING **: GtkSpinButton: setting an adjustment
with non-zero page size is deprecated<br>
  <br>
(jamin:25035): Gtk-WARNING **: GtkSpinButton: setting an adjustment
with non-zero page size is deprecated<br>
  <br>
(jamin:25035): Gtk-WARNING **: GtkSpinButton: setting an adjustment
with non-zero page size is deprecated<br>
[New Thread 0xb6a2fb70 (LWP 25046)]<br>
Started OSC server thread at osc.udp://cvn:4444/<br>
[New Thread 0xb622eb70 (LWP 25047)]<br>
[New Thread 0xb61adb70 (LWP 25048)]<br>
  <br>
Program received signal SIGABRT, Aborted.<br>
[Switching to Thread 0xb622eb70 (LWP 25047)]<br>
0x00b2c422 in __kernel_vsyscall ()<br>
(gdb) thread all apply bt<br>
No symbol "all" in current context.<br>
(gdb) thread apply all bt<br>
  <br>
Thread 5 (Thread 0xb61adb70 (LWP 25048)):<br>
#0&nbsp; 0x007f6651 in ?? () from /usr/lib/libfftw3f.so.3<br>
#1&nbsp; 0x007e4af8 in ?? () from /usr/lib/libfftw3f.so.3<br>
#2&nbsp; 0x007e2466 in ?? () from /usr/lib/libfftw3f.so.3<br>
#3&nbsp; 0x007e9436 in fftwf_rdft_solve () from /usr/lib/libfftw3f.so.3<br>
#4&nbsp; 0x0084cf67 in fftwf_execute () from /usr/lib/libfftw3f.so.3<br>
#5&nbsp; 0x08061534 in run_eq (port=0, in_ptr=128) at process.c:309<br>
#6&nbsp; 0x0806287d in process_signal (nframes=128, nchannels=2,
in=0xb61ad2d8, out=0xb61ad2d0) at process.c:563<br>
#7&nbsp; 0x0805e61e in io_dsp_thread (arg=0x0) at io.c:392<br>
#8&nbsp; 0x0036c8a1 in ?? () from /usr/lib/libjack.so.0<br>
#9&nbsp; 0x008ee80e in start_thread (arg=0xb61adb70) at pthread_create.c:300<br>
#10 0x010c77ee in clone () at
../sysdeps/unix/sysv/linux/i386/clone.S:130<br>
  <br>
Thread 4 (Thread 0xb622eb70 (LWP 25047)):<br>
#0&nbsp; 0x00b2c422 in __kernel_vsyscall ()<br>
#1&nbsp; 0x010254d1 in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64<br>
#2&nbsp; 0x01028932 in *__GI_abort () at abort.c:92<br>
#3&nbsp; 0x0805d90f in io_queue (nframes=64, nchannels=2, in=0xb622e298,
out=0xb622e290) at io.c:480<br>
#4&nbsp; 0x0805d9ab in io_process (nframes=64, arg=0x0) at io.c:548<br>
#5&nbsp; 0x00367b8e in ?? () from /usr/lib/libjack.so.0<br>
#6&nbsp; 0x0036c8a1 in ?? () from /usr/lib/libjack.so.0<br>
#7&nbsp; 0x008ee80e in start_thread (arg=0xb622eb70) at pthread_create.c:300<br>
#8&nbsp; 0x010c77ee in clone () at
../sysdeps/unix/sysv/linux/i386/clone.S:130<br>
  <br>
Thread 3 (Thread 0xb6a2fb70 (LWP 25046)):<br>
#0&nbsp; 0x00b2c422 in __kernel_vsyscall ()<br>
#1&nbsp; 0x010b9ba6 in *__GI___poll (fds=0x113aff4, nfds=1, timeout=10) at
../sysdeps/unix/sysv/linux/poll.c:87<br>
#2&nbsp; 0x0038c125 in lo_server_recv_noblock () from /usr/lib/liblo.so.0<br>
#3&nbsp; 0x0038cc62 in ?? () from /usr/lib/liblo.so.0<br>
#4&nbsp; 0x008ee80e in start_thread (arg=0xb6a2fb70) at pthread_create.c:300<br>
#5&nbsp; 0x010c77ee in clone () at
../sysdeps/unix/sysv/linux/i386/clone.S:130<br>
  <br>
Thread 2 (Thread 0xb7ea8b70 (LWP 25039)):<br>
#0&nbsp; 0x00b2c422 in __kernel_vsyscall ()<br>
#1&nbsp; 0x008f2e15 in <a class="moz-txt-link-abbreviated" href="mailto:pthread_cond_wait@@GLIBC_2.3.2">pthread_cond_wait@@GLIBC_2.3.2</a> ()<br>
&nbsp;&nbsp;&nbsp; at
../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122<br>
#2&nbsp; 0x003699bf in ?? () from /usr/lib/libjack.so.0<br>
#3&nbsp; 0x008ee80e in start_thread (arg=0xb7ea8b70) at pthread_create.c:300<br>
#4&nbsp; 0x010c77ee in clone () at
../sysdeps/unix/sysv/linux/i386/clone.S:130<br>
  <br>
---Type &lt;return&gt; to continue, or q &lt;return&gt; to quit---<br>
Thread 1 (Thread 0xb7fd5720 (LWP 25035)):<br>
#0&nbsp; 0x00b2c422 in __kernel_vsyscall ()<br>
#1&nbsp; 0x010b9ba6 in *__GI___poll (fds=0x113aff4, nfds=8, timeout=74) at
../sysdeps/unix/sysv/linux/poll.c:87<br>
#2&nbsp; 0x002f354b in IA__g_poll (fds=0x82143a8, nfds=8, timeout=74) at
/build/buildd/glib2.0-2.22.3/glib/gpoll.c:127<br>
#3&nbsp; 0x002e656b in g_main_context_poll (context=0x81271d0,
block=&lt;value optimized out&gt;, dispatch=1, self=0x80f70c8)<br>
&nbsp;&nbsp;&nbsp; at /build/buildd/glib2.0-2.22.3/glib/gmain.c:2904<br>
#4&nbsp; g_main_context_iterate (context=0x81271d0, block=&lt;value
optimized out&gt;, dispatch=1, self=0x80f70c8)<br>
&nbsp;&nbsp;&nbsp; at /build/buildd/glib2.0-2.22.3/glib/gmain.c:2586<br>
#5&nbsp; 0x002e6b9f in IA__g_main_loop_run (loop=0x8214210) at
/build/buildd/glib2.0-2.22.3/glib/gmain.c:2799<br>
#6&nbsp; 0x00d71419 in IA__gtk_main () at
/build/buildd/gtk+2.0-2.18.3/gtk/gtkmain.c:1218<br>
#7&nbsp; 0x08060801 in main (argc=3, argv=0xbffff414) at main.c:174<br>
(gdb) <br>
  </tt><br>
</blockquote>
<meta name="qrichtext" content="1">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css">
p, li { white-space: pre-wrap; }
</style>Next, I noticed that running with the standard Ubuntu Jamin,
but with the -t flag (and -p), no abort either, tried it twice with the
Ubuntu Jamin and twice with the cvs Jamin.<br>
<br>
All tests done with <span style="color: rgb(153, 0, 153);">
/usr/bin/jackd -R -dalsa -dhw:0 -r44100 -p64 -n4.</span><br>
<br>
What's next to try?<br>
<br>
Regards,<br>
Kees<br>
<br>
-------- Original Message --------<br>
Subject: Re: [Jamin] ardour export + jamin<br>
From: Jack O'Quin <a class="moz-txt-link-rfc2396E" href="mailto:jac...@gm...">&lt;jac...@gm...&gt;</a><br>
To: Kees van Veen <a class="moz-txt-link-rfc2396E" href="mailto:kee...@gm...">&lt;kee...@gm...&gt;</a><br>
Date: Thu Jan 14 2010 03:28:52 GMT+0100 (CET)<br>
<blockquote
 cite="mid:a07...@ma..."
 type="cite">
  <pre wrap="">On Wed, Jan 13, 2010 at 2:51 PM, Kees van Veen <a class="moz-txt-link-rfc2396E" href="mailto:kee...@gm...">&lt;kee...@gm...&gt;</a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Jack,

Can't get it to abort when the Jack period is 256. Tried it several times
without aborting. My .jackdrc then was: /usr/bin/jackd -R -dalsa -dhw:0
-r44100 -p256 -n2

As soon as I changed my jack settings to 64 frames: /usr/bin/jackd -R -dalsa
-dhw:0 -r44100 -p64 -n4, Jamin aborted at the end of the first export I
tried.

I've attached the gdb.log with the content you asked. Kernel: Linux
2.6.31-9-rt #152-Ubuntu SMP PREEMPT RT Thu Oct 15 05:01:14 UTC 2009 i686
GNU/Linux. All packages from the Ubuntu Karmic standard repos.

Changing the jack settings to 128 frames: /usr/bin/jackd -R -dalsa -dhw:0
-r44100 -p128 -n2, did not show the abort either, tried it several times in
a row.

As soon as I changed it back to 64 as above, trouble started again.

I'm very curious about the magical 256/128 ...
    </pre>
  </blockquote>
  <pre wrap=""><!---->
The natural FFT window size for the signal processing component of
jamin is 256 frames.

If JACK is running with a smaller window size, then jamin needs to
queue the processing to a lower-priority real-time thread so it has
enough time to perform the FFT (which is computationally expensive)
while still meeting the JACK audio processing deadlines.

As Jan mentioned, there is really no good reason to run JACK with low
latency settings during mastering (at least none that we know).  But,
I added the multithreaded implementation in an effort to handle that
case correctly, anyway.

Apparently, it is failing when JACK is running in freewheeling mode.
Everything I've seen so far indicates that "linuxdsp" is probably
right about the cause.  I don't think freewheeling mode existed when
jamin was written back in 2003, so that case (plus low latency)
probably did not get tested at the time.

  </pre>
  <blockquote type="cite">
    <pre wrap="">If you need more info, or want me to try other things, let me know.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
That would be helpful, if you don't mind continuing to act as my eyes
and ears.  I don't currently have a system configured properly to
reproduce this failure.

There are a couple of things I'd like to try, if you are willing.

First, try running the failure case (-p64) with the jamin -T option
and send us the trace buffer output.  That might help to confirm the
diagnosis.

Second, your gdb traceback differs by a few lines from the current CVS
sources.  There have not been any major changes to that part of the
code in years.  But, I'd like to send you a patch or two to try, and
would prefer to do it against CVS.

So, would you mind updating jamin to the current CVS, so we can run
the test with that?

Thanks for all your help.  I believe we can come up with a simple
solution that works reliably in the freewheeling case without
disturbing the timing of everything else.

Regards,
  </pre>
</blockquote>
<br>
<br>
</body>
</html>

Re: [Jamin] ardour export + jamin

[Kees v. V. <kee...@gm...>]

Jack,

Tried your fix, but it failed, i.e. again abort(), but not at the end of 
the export, but after I'd let Ardour play again, so I figured that the 
transition between the -t behaviour when freewheeling and back to dsp 
thread would cause that, so I fiddled around with putting io_cleanup() 
before changing the freewheeling static in the freewheel callback and 
calling io_activate() again, but that didn't work.

Then I tried in the freewheel callback to call 
io_new_state(DSP_STOPPED), just before changing the freewheeling static. 
Now I get - jamin internal error 35: invalid DSP state transition: 010 
-> 040 - each time I switch between export and play, but it does not 
abort() anymore. Haven't listened to all of the exported file, but at 
least the start of it seemed ok (mixed with the TV noise of the family). 
Tried that several times in a row in one ardour/jamin session. Since I 
tried that with the CVS version, I also patched the Ubuntu standard 
version, ran that with the exact same results. So the state transition 
is illegal, but I don't have enough knowledge of jamin to figure that 
out, maybe this gives you some more information as to a next step. All 
tests done with /usr/bin/jackd -R -dalsa -dhw:0 -r44100 -p64 -n4 , I 
guess other frames/period settings will be ok as well. Let me know if 
that would provide additional info, I'll try that as well.

Cheers,
Kees

-------- Original Message --------
Subject: Re: [Jamin] ardour export + jamin
From: Jack O'Quin <jac...@gm...>
To: Kees van Veen <kee...@gm...>
Date: Fri Jan 15 2010 03:11:13 GMT+0100 (CET)
> On Thu, Jan 14, 2010 at 3:35 PM, Kees van Veen <kee...@gm...> wrote:
>   
>> Jack,
>>
>> I tried running Jamin from the Ubuntu repos (not even in debug, but
>> stripped) with the -T flag and jack -p64 -n4, which aborted, but no file, no
>> stderr output (as I gather -T flag should provide). Remake in debug made no
>> difference.
>>     
>
> D'oh!  The -T does nothing in the abort() case, where it's most
> needed.  I'll try to come up with a fix for that later.
>
>   
>> Then I tried the latest CVS tree, ./configure without options, make, make
>> install.
>> (At first it wouldn't abort, tried it several times, but then I discovered
>> my patched io.c was still in the tree :-[ , removed it, cvs update, cvs
>> diff, make, make install, then it aborted).
>>     
>
>
>   
>> Next, I noticed that running with the standard Ubuntu Jamin, but with the -t
>> flag (and -p), no abort either, tried it twice with the Ubuntu Jamin and
>> twice with the cvs Jamin.
>>     
>
> That's good to know.  Good idea to try -t.
>
>   
>> All tests done with /usr/bin/jackd -R -dalsa -dhw:0 -r44100 -p64 -n4.
>>
>> What's next to try?
>>     
>
> Given that -t seems to work, I worked up a simplified version of your
> patch that should solve your problem, hopefully without introducing
> any other artifacts or undesirable timing changes.  Essentially, it
> does the same as -t, but only when JACK is freewheeling.  I used your
> code for defining the JACK freewheel callback.
>
> Please give it a try both with and without freewheeling and at both
> large and small period sizes.
>
> There may be some DSP artifacts due to using a smaller FFT window that
> could cause slightly different output depending on whether
> freewheeling is enabled.  Steve Harris probably knows whether this
> makes a difference or not.  If it does, I doubt any differences would
> be audible.
>
> Regards,
>   

Re: [Jamin] ardour export + jamin

[Kees v. V. <kee...@gm...>]

Was wrong about the abort(): after 4 times export and then play, it 
still aborted ...

-------- Original Message --------
Subject: Re: [Jamin] ardour export + jamin
From: Kees van Veen <kee...@gm...>
To: Jack O'Quin <jac...@gm...>
Date: Fri Jan 15 2010 21:34:13 GMT+0100 (CET)
> Jack,
>
> Tried your fix, but it failed, i.e. again abort(), but not at the end 
> of the export, but after I'd let Ardour play again, so I figured that 
> the transition between the -t behaviour when freewheeling and back to 
> dsp thread would cause that, so I fiddled around with putting 
> io_cleanup() before changing the freewheeling static in the freewheel 
> callback and calling io_activate() again, but that didn't work.
>
> Then I tried in the freewheel callback to call 
> io_new_state(DSP_STOPPED), just before changing the freewheeling 
> static. Now I get - jamin internal error 35: invalid DSP state 
> transition: 010 -> 040 - each time I switch between export and play, 
> but it does not abort() anymore. Haven't listened to all of the 
> exported file, but at least the start of it seemed ok (mixed with the 
> TV noise of the family). Tried that several times in a row in one 
> ardour/jamin session. Since I tried that with the CVS version, I also 
> patched the Ubuntu standard version, ran that with the exact same 
> results. So the state transition is illegal, but I don't have enough 
> knowledge of jamin to figure that out, maybe this gives you some more 
> information as to a next step. All tests done with /usr/bin/jackd -R 
> -dalsa -dhw:0 -r44100 -p64 -n4 , I guess other frames/period settings 
> will be ok as well. Let me know if that would provide additional info, 
> I'll try that as well.
>
> Cheers,
> Kees
>
> -------- Original Message --------
> Subject: Re: [Jamin] ardour export + jamin
> From: Jack O'Quin <jac...@gm...>
> To: Kees van Veen <kee...@gm...>
> Date: Fri Jan 15 2010 03:11:13 GMT+0100 (CET)
>> On Thu, Jan 14, 2010 at 3:35 PM, Kees van Veen 
>> <kee...@gm...> wrote:
>>  
>>> Jack,
>>>
>>> I tried running Jamin from the Ubuntu repos (not even in debug, but
>>> stripped) with the -T flag and jack -p64 -n4, which aborted, but no 
>>> file, no
>>> stderr output (as I gather -T flag should provide). Remake in debug 
>>> made no
>>> difference.
>>>     
>>
>> D'oh!  The -T does nothing in the abort() case, where it's most
>> needed.  I'll try to come up with a fix for that later.
>>
>>  
>>> Then I tried the latest CVS tree, ./configure without options, make, 
>>> make
>>> install.
>>> (At first it wouldn't abort, tried it several times, but then I 
>>> discovered
>>> my patched io.c was still in the tree :-[ , removed it, cvs update, cvs
>>> diff, make, make install, then it aborted).
>>>     
>>
>>
>>  
>>> Next, I noticed that running with the standard Ubuntu Jamin, but 
>>> with the -t
>>> flag (and -p), no abort either, tried it twice with the Ubuntu Jamin 
>>> and
>>> twice with the cvs Jamin.
>>>     
>>
>> That's good to know.  Good idea to try -t.
>>
>>  
>>> All tests done with /usr/bin/jackd -R -dalsa -dhw:0 -r44100 -p64 -n4.
>>>
>>> What's next to try?
>>>     
>>
>> Given that -t seems to work, I worked up a simplified version of your
>> patch that should solve your problem, hopefully without introducing
>> any other artifacts or undesirable timing changes.  Essentially, it
>> does the same as -t, but only when JACK is freewheeling.  I used your
>> code for defining the JACK freewheel callback.
>>
>> Please give it a try both with and without freewheeling and at both
>> large and small period sizes.
>>
>> There may be some DSP artifacts due to using a smaller FFT window that
>> could cause slightly different output depending on whether
>> freewheeling is enabled.  Steve Harris probably knows whether this
>> makes a difference or not.  If it does, I doubt any differences would
>> be audible.
>>
>> Regards,
>>   
>
>

Re: [Jamin] ardour export + jamin

[Kees v. V. <kee...@gm...>]

Hi Jack,

Thanks for your help, so far. At least I have a work-around, so that 
gives me some air, and it's good we found the cause of the trouble.

Looks like you still do development on Jamin, but no new version has 
been released for some time. Are you guys planning one?

Regards,
Kees

-------- Original Message --------
Subject: Re: [Jamin] ardour export + jamin
From: Jack O'Quin <jac...@gm...>
To: Kees van Veen <kee...@gm...>
Date: Sat Jan 16 2010 00:46:30 GMT+0100 (CET)
> On Fri, Jan 15, 2010 at 2:43 PM, Kees van Veen <kee...@gm...> wrote:
>   
>> Was wrong about the abort(): after 4 times export and then play, it still
>> aborted ...
>>     
>
> I think the problem with the current freewheeling patch is that it
> assumes we can switch back and forth between the two modes on any
> process() call.  But, at -p64 there are anywhere from 0 to 3 previous
> input and output buffers queued for the DSP thread.  So, we need to
> drain the queues before making the transition.
>
> Sounds like that requires an additional state or two.
>
> I may not have enough time to work on this for a few days.  I have
> deadlines looming on other projects.
>   

Re: [Jamin] ardour export + jamin

[Kees v. V. <kee...@gm...>]

Jack,

Just a thought: since it only happens with low frames/period and 
freewheeling, it would also be possible to issue a warning when the 
condition fails (and maybe to slow down Jack a bit in freewheeling mode, 
if no harm is done (still the wrong solution, I know, but it would 
complete the export)), and ask Jack for the current frames/period 
setting, so the user will know why Jamin is aborted (or Jack is slowed 
down).

That way this issue would not get in the way of a new release, and still 
give the user a clue as to what is happening. Might also generate more 
specific posts of the problem. It took me a while before I knew why 
Jamin 'disappeared' all of a sudden. If you're new to using Ardour, 
Jack, Jamin, you often look in the wrong places, thinking you did 
something wrong with the insert or something.

If I can be of any help, let me know.

Regards,
Kees

-------- Original Message --------
Subject: Re: [Jamin] ardour export + jamin
From: Jack O'Quin <jac...@gm...>
To: Kees van Veen <kee...@gm...>
Date: Mon Jan 18 2010 16:38:28 GMT+0100 (CET)
> On Mon, Jan 18, 2010 at 6:51 AM, Kees van Veen <kee...@gm...> wrote:
>   
>> Hi Jack,
>>
>> Thanks for your help, so far. At least I have a work-around, so that gives
>> me some air, and it's good we found the cause of the trouble.
>>
>> Looks like you still do development on Jamin, but no new version has been
>> released for some time. Are you guys planning one?
>>     
>
> Yes, I think we will.  There are a couple of small but useful
> enhancements in CVS already.  Once we can come up with a solid fix to
> this "low-latency freewheeling" bug, it needs to be released.  I'm
> still not sure exactly what a good solution will look like; I am not
> eager to do a major rewrite of those DSP queuing states.  Meanwhile, I
> think the recommended work-around is to use a period size of a least
> 256 samples.
>
> Jamin has been in maintenance mode for quite some time.  It seems to
> work well for most purposes and sounds good, so there's been no
> pressure to make new releases.  (If it ain't broke, don't fix it.)
>
> I wish we'd known about the freewheeling problem sooner, but I don't
> recall it being reported here, and don't follow the Ardour forums
> myself.  Thanks for letting us know about the problem.
>