Progress!

OK, my sfront jack-output driver is now doing this much:

- compiling
- running without segfault
- connecting to running jackd
- getting its process() called by jackd
  (actually I named it asysn_jack_process() in accordance with
   my understanding of sfront's naming conventions).

But I don't hear anything yet.

asysn_jack_process() was largely copied from
the sfront portaudio driver, and it looks like the following.
Excessive comments show what I *think* is going on...
Can anybody spot what's borken?

One more thing: I registered a function asysn_jack_set_srate()
which only increments a counter called asysn_jack_srate_was_called.
AFAICT, this function gets called once when the client connects.
Originally I had this function call return(1) to force immediate 
termination of the client, but the result was that I never got
running! So now I'm testing asysn_jack_srate_was_called and
I exit if it's > 1.

-----------------

int asysn_jack_process (nframes_t nframes, void * arg )
   /*  Hmmm... don't think I need it. */
{
  /* vars. copied from portaudio driver....

Re: Progress!

> Can anybody spot what's borken?

Sometimes the shortest path to fixing a "nothing happens
at all" sort of bug is to rule out the extreme cases.
For example, 

  -- Take the same SAOL + SASL example, write it to a 
     file using -aout test.wav, and make sure you're
     not hearing silience out of jack because you are
     playing silience into it.

  -- Leave the looping the same, but replace the call
     to asys_orun(&(obuf[optr]), &osize); with a loop
     that fills up obuf with random noise -- this gets
     much of sfront out of the loop, if this noise
     generator example also makes no sound.

This sort of divide and conquer strategy can at least
hone the problem done so you know what to stare at ...

						--jl

Re: Re: Progress!

On Tue, Apr 30, 2002 at 05:41:12PM -0700, John Lazzaro wrote:
> Sometimes the shortest path to fixing a "nothing happens
> at all" sort of bug is to rule out the extreme cases.
> For example, 
> 
>   -- Take the same SAOL + SASL example, write it to a 
>      file using -aout test.wav, and make sure you're
>      not hearing silience out of jack because you are
>      playing silience into it.

Well, I'm running the rtime/linmidi example, with
some additional link options to get it to compile against jack.

>   -- Leave the looping the same, but replace the call
>      to asys_orun(&(obuf[optr]), &osize); with a loop
>      that fills up obuf with random noise -- this gets
>      much of sfront out of the loop, if this noise
>      generator example also makes no sound.

OK... trying that...

hang on! I missed this in the jack messages: my client is timing out.
Apparently it's been happening all along.
I have an idea why... more later....

thanks for the advice!
--

-- 

Paul Winkler
home:  http://www.slinkp.com

Re: Progress!

On Tue, 30 Apr 2002, Paul Winkler wrote:

> OK, my sfront jack-output driver is now doing this much:
> 
> - compiling
> - running without segfault
> - connecting to running jackd
> - getting its process() called by jackd
>   (actually I named it asysn_jack_process() in accordance with
>    my understanding of sfront's naming conventions).
> 
> But I don't hear anything yet.

have you registered the ports? are they connected? if the ports aren't
connected, silence would be normal.

seems obvious, but i ran into this too ;)

cheers,

wingo.

Re: Re: Progress!

> I have an idea why... more later....

Good luck!

I'll probably be away from the terminal for the next
few hours, so don't expect any addition replies to
the morning ...

						--jl

Re: Re: Progress!

On Tue, Apr 30, 2002 at 09:53:01PM -0400, Paul Winkler wrote:
re. timeouts:
> I have an idea why... more later....

... nope. no idea now. :(

Here's what jack gives me:
$ jackd -d alsa -d Delta66
jackd 0.28.0
Copyright 2001-2002 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

creating alsa driver ... Delta66|1024|2|48000|swmon

(then all's OK until I start my client, then I get this:)

subgraph starting at SAOL Test Client timed out (subgraph_wait_fd=13,
status = 134633936, state = Running)

(then I hit Ctrl-C to stop jack)

jackd: signal 2 received
jack main caught signal 15

-------

So what's going on there? "state=Running" is encouraging,
and I'm seeing printfs from my code that indicate that

Re: Re: Progress!

Hi Paul,

	It's a little hard to tell, given the number of 
items commented out, but there's a few possible places
where the main loop:

  while (asysn_jack_proc_status == ASYS_DONE) {
  }

	in asysn_jack_process may be broken, depending
on which comments you uncomment and what order. Namely:

[1] asysn_jack_proc_status is never initialized at the
before the while -- it's taking on whatever value it 
had before. Also, when things are as commented-out as
the version you sent along, it doesn't look like 
asysn_jack_proc_status ever changes inside the loop,
so the loop can go forever.

[2] The order of updating optr is wrong -- think in
terms of the first time a obuf[optr]= assignment 
happens, you want that assignment to be for obuf[0].
But it loops like you update optr before then.

	My guess is that these factors combine somehow,
and you get stuck in this while loop infinitely long,
and that's why a time out happens. 

	Your best bet might be to strip out the loop
entirely to start, and just use memcpy to zero out

jackd just keeps on running

The current CVS-tree seems to work extremely well. I've had jackd running
without a single restart for few days with constant audio operation
(including _lots_ of heavy-load situations, constant modifying of
connections, plus sometimes even buggy clients). Judging from
/proc/interrupts, jackd has processed around 100h of audio. :) So things
are looking good!

I guess we should start planning for making the first public tarball
release. The two big issues still open are port latency calculations and
transport control. More precisely the current CVS-tree offers a solution
to both these issues, but nobody has had time to test/verify these (or at
least I haven't :)). On the other hand these are important features, and
if problems are found, API changes are probably needed. Has there been any
new development on jack+ardour front with these issues (*)?

As for ecasound's JACK-support, in the current ecasound CVS-tree JACK
input/output now works just as well as ALSA and OSS. Only big limitation
is that for multitrack sync calculations JACK input port latency is
hardcoded to be one period. I intend to fix this before releasing 2.1dev8
(this also involves going through JACK's latency-related code).

(*) I'm not subscribed to ardour-devel so I might have missed 
    some JACK-related threads there...

--

-- 
 http://www.eca.cx
 Audio software for Linux!

_______________________________________________________________

introduction, proposal and first patchie

hi,

I'am on LAD for a while and now decided to have a go with jack. I've wrote a two mails to Paul
today directly telling him, that I am interested in alternative drivers as I am bound to solaris here.
Further I would like to help to improve documentation.
While brwosing todays cvs source I noticed the following two things.
1.) wouldn't it be better to have a non-flat dir-hierachy. E.g having :
clients/
   capture.c
   monitor.c
   simple.c
drivers/
   alsa/
     alsa_driver.c (can now be named just "driver.c")
     hammerfall.c
   esound/
     driver.c

Of couse this would mean, asking sf-personel to move the files, so that you don't lose the history.
All people with commit rights shouldn't have uncommited work on the hd. On the other hand it would
be better to do this before the dir gets too crowded.

2.) I would love to see at least a 3 line comment on top of each file (after t
he header comment),
giving a rough idea what it is for.
impule_grabber.c has not even the standard header .
-- please find a patch attached for this simple one
Further having README and INSTALL files in CVS would hurt either.

I will try to see if I can get  a esound based backend working. Its purpose is just to get

revised patch

hi again,

Some more infos. The deep directory suggestion is mainly neccesary to easily enable/disable
drivers when configuring the package (you don't want to add #ifdef HAVE_ALSA everywhere  ).

And I extended the patchie a litle.

Stefan
-- 
       \|/
      < <at>   <at> > Stefan Kost  private                   business
+-oOO-(_)-OOo------------------------------------------------------------- - - -  -   -
|        __    Address  Zwenkauer Str. 24         HTWK Leipzig, Fb IMN, Postfach 300066
|       ///             04277 Leipzig             04277 Leipzig
|  __  ///              Germany                   Germany
|  \\\///      Phone    +49341 3910483            +49341 30766101
|   \__/       EMail    st_kost <at> gmx.net           kost <at> imn.htwk-leipzig.de
|              WWW      http://www.sonicpulse.de  http://www.imn.htwk-leipzig.de/~kost/about.html
===-=-=--=---=---------------------------------- - - -  -    -

--- impulse_grabber.c.old	Fri May  3 16:10:13 2002
+++ impulse_grabber.c	Fri May  3 16:30:46 2002
 <at>  <at>  -1,3 +1,23  <at>  <at> 
+/*
+    Copyright (C) 2001 Paul Davis
+    
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or