latest SVN commits

so, in the lull while we wait for the last few details of
ardour2 to
fall into place, i'm getting back to trying to wrap up some
loose ends
with JACK. today i:

  a) implemented Fon's proposed jack_thread_wait() API,
along with his
        suggested internal code design that allows to use
the exact
	same code path for callback or blocking clients. Excellent
        proposal from Fons (no suprise there), it helped
clean up
        that code quite a bit.

  b) removed jack_port_lock() and jack_port_unlock().
AFAICT, this 
       affects only PortAudio v19's own support of JACK.
These
       functions were a thorn in the side of the API and 
       needed to be removed. Contrary to Fons' comment, I
absolutely
       do not consider them useful. I did leave in place
the
       member of the port structure that they used to use
(renamed)
       to keep binary compatibility in clients that do not
use
       these calls (i.e. 99% of all clients)

  c) add Dmitry's jack_get_time() call to expose
jack_get_microseconds()

  d) added Dmitry's jack_frame_to_time() and
jack_time_frame() calls,
       to allow clients to use JACK's internal DLL's more
easily
  
  e) applied 4 small patches that have been in the mailing
list queue
       for a while:

        - allow automatic detection of big-endian signed 16
bit format
              in the ALSA backend
        - fix man page description of period size
        - change memory alignment for better SIMD
performance
        - change order of arguments in call to snd_pcm_link

  f) bumped library version to 0.24.0

Within the next week, I would like to wrap up any issues
relating to
the release of JACK 1.0. From my perspective, the major ones
now relate
mostly to 

    * merging the MIDI branch back into trunk
    * our feeble website and its meagre documentation and
explication.

I don't claim to know if the current MIDI branch can be
considered ready
for this merge - comments please.

--p



------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

Paul Davis wrote:
...
> Within the next week, I would like to wrap up any
issues relating to
> the release of JACK 1.0. From my perspective, the major
ones now relate
> mostly to 
...

I'm glad to see that the 0. prefix is starting to disappear
on both 
Ardour & Jack ;).

I wonder if it is worthwhile to try and get the backend for
FFADO in 
shape for 1.0. It sort of depends on the release plan for
jack after 
1.0. I would like to release a first FFADO version within
the next two 
(or maybe four) months, and it would be nice if Jack
supported FFADO out 
of the box. So either it is a 1.x.y release that adds this
backend, or 
it is already in there.

The backend ('firewire') itself is a slightly modified
version of the 
FreeBoB backend, and can IMHO be considered equally stable.

The only thing missing in the backend (and the FFADO API) is
jack-midi 
support, which would be nice because FireWire does sample
accurate Midi 
transport, and that would allow me to drop the alsa-seq
support. (there 
is a jack-midi <=> aseq bridge no?)

A rather big issue is that the FFADO API we use for the
FireWire backend 
is fixed as from the moment it is used in a 1.0. I don't
think it is 
ready for that yet.

To summarize:
* I'd like the firewire backend in 1.0
* TODO (in order of difficulty):
   1) firewire backend port
   2) jack-midi
   3) API cleanup & future-proofing

What would be the timeframe of the 1.0 freeze / release? I
would expect 
that merging in jack-midi and the likes will need some
testing too?

Greets,

Pieter

------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

Paul Davis wrote:

>   f) bumped library version to 0.24.0
> 

Wouldn't it be best to also bump the normal version?

Pieter

------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

On 16/04/07, Paul Davis <paullinuxaudiosystems.com>
wrote:
> Within the next week, I would like to wrap up any
issues relating to
> the release of JACK 1.0.

There are still some outstanding bugs on FreeBSD that should
be
fixed (or at least this is a humble request that somebody
fix them).

I offered a shell account to Jack O'Quinn to fix them, but
he seems
to have fallen off the edge of the world (Please don't take
this as a
personal attack in any way, Jack, I know you're a busy
man).

Anybody else feel like taking a shot at them?

Jack hasn't actually compiled properly on FreeBSD 6 for
quite some
time. Also, on my system there's a floating point exception
error
whilst using any backend (including dummy).

MC

------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

Le 16 avr. 07 à 03:42, Paul Davis a écrit :

> so, in the lull while we wait for the last few details
of ardour2 to
> fall into place, i'm getting back to trying to wrap up
some loose ends
> with JACK. today i:
>
>   a) implemented Fon's proposed jack_thread_wait() API,
along with his
>         suggested internal code design that allows to
use the exact
> 	same code path for callback or blocking clients.
Excellent
>         proposal from Fons (no suprise there), it
helped clean up
>         that code quite a bit.

I'm very confused with your implementation and the
jack_thread_wait  
documentation included in jack.h

1)   nframes = jack_thread_wait (client, 0);

      while (TRUE) {
           nframes = jack_thread_wait (client,
do_some_processing  
(nframes));
      }

Why is this structure needed?  (i've implemented a simple
client that  
uses the new API in jackdmp with a simpler design)



2) I don't understand the "Therefore, this loop should
run in its own  
thread which should probably have been created with function 

jack_client_create_thread()" comment

3) I don't understand "Clients using this call should
probably not  
call  function jack_set_process_callback although it is not
an error  
for them to do so" comment also...

Stephane

------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

On Sun, Apr 15, 2007 at 09:42:01PM -0400, Paul Davis wrote:

>   a) implemented Fon's proposed jack_thread_wait() API,
along with his
>         suggested internal code design that allows to
use the exact
> 	same code path for callback or blocking clients.
Excellent
>         proposal from Fons (no suprise there), it
helped clean up
>         that code quite a bit.

Judging from the comments in jack.h it looks you implemented

something quite different. Also as presented there, there
is
no advantage over using a callback - the function called
'do_some_processing()' is in fact identical to the normal
callback, and the only difference is that the enclosing
loop
is now in the user code rather than the library.

The whole point of the waiting system is that it allows
to client to wait for next period _without_ having to
return from a function, in other words it allows the client
to remain in the scope and context it may need to continue
working when the next period arrives.

Also it has never been the intention to let a client use
its
own thread, and not register a callback.

The intention is to use jack_thread_wait() from _within_
the
process callback. Either the callback returns (with a non-
zero value) and then it called again on the next period,
or it calls jack_thread_wait() and then execution continues
from that point next time. The code structure I suggested
even made it completely inconsequential to know, within
the library, which of the two happened as the same actions
would be required in both cases. 

Looking again at the proposed code stucture it seems indeed
that it is possible to let a client use its own thread, but
allowing for this complicates the otherwise very simple
code structure in two ways:

- There must be a branch somewhere depending on the 
  existence of a process_callback(). Except for error
  handling this should not be unnecessary.

- As presented now, jack_thread_wait() could be called
  before the library's client data is initialised and
  therefore  must include some extra code to handle this.
  Again this not necessary if can only be called legally
  from within the callback, as proposed.


-- 
FA

Follie! Follie! Delirio vano è questo !



------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

On Mon, 2007-04-16 at 12:22 +0200, Fons Adriaensen wrote:
> On Sun, Apr 15, 2007 at 09:42:01PM -0400, Paul Davis
wrote:
> 
> >   a) implemented Fon's proposed jack_thread_wait()
API, along with his
> >         suggested internal code design that allows
to use the exact
> > 	same code path for callback or blocking clients.
Excellent
> >         proposal from Fons (no suprise there), it
helped clean up
> >         that code quite a bit.
> 
> Judging from the comments in jack.h it looks you
implemented 
> something quite different.

OK. Clearly I misunderstood the context of this comment from
you:

"This example shows the essential point of the new
interface: the outer
loop of the jack thread (the while (1) in the example above)
has been
moved from within libjack into the user code."

you will presumably see the similarity with what you wrote
here:

" Also as presented there, there is no advantage over
using a callback -
the function called 'do_some_processing()' is in fact
identical to the
normal callback, and the only difference is that the
enclosing loop is
now in the user code rather than the library."

 ?

In re-reading that context, its clear that you still
intended the
user-code in question to be called from within a
libjack-managed thread
via jack_set_process_function(), which was a part of the API
that i
missed out on in focusing on the discussion between you and
stephane
about precisely how to implement it.

> The whole point of the waiting system is that it
allows
> to client to wait for next period _without_ having to
> return from a function, in other words it allows the
client
> to remain in the scope and context it may need to
continue
> working when the next period arrives.

understood, i will modify that.




------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

On Mon, 2007-04-16 at 11:00 +0200, Stéphane Letz wrote:

Stephane, in reviewing jackdmp's code, its not clear to me
that you
added jack_set_process_function() as an alternative
execution model. 
Am I just missing it?

I am asking because Fons' brief outline skips out the rather
important
steps of calling the sync+timebase callbacks for clients
that have them
set.




------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

Hi Paul,

> OK. Clearly I misunderstood the context of this comment
from you:
> 
> "This example shows the essential point of the new
interface: the outer
> loop of the jack thread (the while (1) in the example
above) has been
> moved from within libjack into the user code."

> you will presumably see the similarity with what you
wrote here:
> 
> " Also as presented there, there is no advantage
over using a callback -
> the function called 'do_some_processing()' is in fact
identical to the
> normal callback, and the only difference is that the
enclosing loop is
> now in the user code rather than the library."
> 

Yes, I wrote that in the early on in the discussion, when
the idea
still was to have two separate 'modes', as in my original
proposal
of times long gone.

The analysis that followed, and that led to the code
structure I
finally proposed, showed that this was not necessary - it
was easy
to integrate the two, if we just called the waiting function
from
within the process callback. This moved the loop back into
library.
For a client using the pure callback model, the loop would
serve
its original purpose. When the client would use the
'waiting' model
the loop would be redundant, as in that case the process
callback
would never return. But since the loop is there anyway, it
allows
the client to even mix both modes - things will
automagically fall
in place even then.

I other words, nothing essential has changed. All the code
that
is now in jack_thread_wait() was already present, and the
only
change is that it has been factored out into a
client-callable
function.

> In re-reading that context, its clear that you still
intended the
> user-code in question to be called from within a
libjack-managed thread
> via jack_set_process_function(), which was a part of
the API that i
> missed out on in focusing on the discussion between you
and stephane
> about precisely how to implement it.

Yes. Your comments in jack.h revealed to me that a client
_could_
use its own thread, but I see no point in doing that. The
one set
up by the library will have all the necessary features (the
correct
priority etc.) and it can alo be terminated and cleaned up
by the
library without any ill effect on the client.

> > The whole point of the waiting system is that it
allows
> > to client to wait for next period _without_ having
to
> > return from a function, in other words it allows
the client
> > to remain in the scope and context it may need to
continue
> > working when the next period arrives.
> 
> understood, i will modify that.

Fine, TNX


-- 
FA

Follie! Follie! Delirio vano è questo !



------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

On Mon, Apr 16, 2007 at 08:18:21AM -0400, Paul Davis wrote:
> On Mon, 2007-04-16 at 11:00 +0200, Stéphane Letz
wrote:
> 
> Stephane, in reviewing jackdmp's code, its not clear to
me that you
> added jack_set_process_function() as an alternative
execution model. 
> Am I just missing it?
> 
> I am asking because Fons' brief outline skips out the
rather important
> steps of calling the sync+timebase callbacks for
clients that have them
> set.

Jack_set_process_function() was part of an older API, before
we 
discovered the more elegant way used now.

It's no longer required, as it turned out that it would be
identical
to jack_set_process_callback(), and the two would be used in
exactly
the same way by the library. Any code selecting between them
would
be redundant.

-- 
FA

Follie! Follie! Delirio vano è questo !



------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el