Re: Help with writing jack client

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Help with writing jack client

Gavin Band
Hi,
Thanks for the responses.

>
> Difficult to say with so little information.
>  
> - are there any error messages from jack ?
>

I don't know, but I will have a look when I get some time.

> - what is the complete command line you use to start jack
>   (i.e. all options)

I used qjackctl, it ran:
"/usr/bin/jackd -v -R -t1000 -dalsa -r44100 -p512 -n2 -D -Chw:0 -Phw:0
-s -i2 -o2"

(Actually I think I had the period set to 256).

> - what are you doing in the process callback - calculations,
>   reading a file, if so how, etc.

Calculations.  The process callback looks like this:

int jackProcess( jack_nframes_t nframes, void* arg )
{
if( nframes > bufferSize )
nframes = bufferSize;

// sound processing occurs here, it puts nframes samples
// into outBufferL and outBufferR

sample_t* outR = ( sample_t * )
    jack_port_get_buffer( outputPortRight, nframes );
sample_t* outL = ( sample_t * )
       jack_port_get_buffer( outputPortLeft, nframes );

memcpy( outL, outBufferL, sizeof (sample_t) * nframes );
memcpy( outR, outBufferR, sizeof (sample_t) * nframes );

return 0;
}

I've omitted the processing, which is quite involved, but I don't think
it is doing any file reads or blocking calls and so on...that's
something I could check.

My other jack callbacks are basically no-ops --- I'm not doing anything
to deal with xruns, or anything like that.  Should I be doing something?

> - is the process callback communicating with other parts
> of your app, and if so how ?

Yes, there are other threads running -- a GUI thread and a MIDI thread
-- and they use shared memory to communicate.  This communication is
through non-locked ints and floats, though, so I don't think this is
causing blocking.  Again this is something I can check.

> > I wonder: does this indicate simply that my client is not managing to
> > produce its output to the server fast enough, or does it indicate that
> > it is doing something more serious wrong?  (If the former, I am sort of
> > surprised that it corrupts the whole jack server.  If the latter, are
> > there any guesses as to what might be going wrong?)
>
> If your app is too slow then some others may no even get the
> chance to be fast enough. All processing for any cycle needs
> to be finished before the next cycle is anbout to start.
>

I see -- but after my app has been kicked out of the jack pipeline,
could it still affect other apps this way?  (I suppose it's possible one
of the other threads is hanging, or something like that, and thus using
a great deal of CPU.  The corruption of sound from the jack server (or
from the other apps connected to it) carried on even after my app was
killed).

Many thanks again,
Gavin Band.




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

Reply | Threaded
Open this post in threaded view
|

Re: Help with writing jack client

Fons Adriaensen-2
On Sun, Feb 24, 2008 at 08:54:40PM +0000, Gavin Band wrote:

> I used qjackctl, it ran:
> "/usr/bin/jackd -v -R -t1000 -dalsa -r44100 -p512 -n2 -D -Chw:0 -Phw:0
> -s -i2 -o2"

Looks OK.
 

> Calculations.  The process callback looks like this:
>
> int jackProcess( jack_nframes_t nframes, void* arg )
> {
> if( nframes > bufferSize )
> nframes = bufferSize;
>
> // sound processing occurs here, it puts nframes samples
> // into outBufferL and outBufferR
>
> sample_t* outR = ( sample_t * )
>     jack_port_get_buffer( outputPortRight, nframes );
> sample_t* outL = ( sample_t * )
>        jack_port_get_buffer( outputPortLeft, nframes );
>
> memcpy( outL, outBufferL, sizeof (sample_t) * nframes );
> memcpy( outR, outBufferR, sizeof (sample_t) * nframes );
>
> return 0;
> }

Why

> if( nframes > bufferSize ) nframes = bufferSize;

???

You *have to* deliver 'nframes' frames. Not negociable AFAIK.
This means also that you could as well move up the get_buffer
calls and write directly to these pointers, dumping the
intermediate buffers.

I wonder, if bufferSize < nframes, you would not fill up
jack's buffers. If any NaN or Inf are left there, that
would generate trouble.

> My other jack callbacks are basically no-ops --- I'm not doing anything
> to deal with xruns, or anything like that.  Should I be doing something?

None of them are essential as long as life is peace.
 
> > - is the process callback communicating with other parts
> > of your app, and if so how ?
>
> Yes, there are other threads running -- a GUI thread and a MIDI thread
> -- and they use shared memory to communicate.  This communication is
> through non-locked ints and floats, though, so I don't think this is
> causing blocking.  Again this is something I can check.

Yes, you should check this.

> I see -- but after my app has been kicked out of the jack pipeline,
> could it still affect other apps this way?  (I suppose it's possible one
> of the other threads is hanging, or something like that, and thus using
> a great deal of CPU.  The corruption of sound from the jack server (or
> from the other apps connected to it) carried on even after my app was
> killed).

That is indeed the strange part of this problem. Normally when
a non-behaving app gets kicked out, jackd manages to get on with
life. This caused me to believe you were writing outside the
buffers or something similar, but your memcpy() seems to exclude
that.

--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel