Upcoming release

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

Upcoming release

Taybin Rutkin
I'd really like to push a new release out, due to the osx 10.4 fix from sletz, and the lack of releases the past couple months.  Since no one commented on my last email about remaining issues, except for pointing to a patch which I'm not sure should be applied or not and can be held for later, I'll put out a release this weekend unless someone stops me. :)

Taybin


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release

rj (Bugzilla)
Hi,

On Thursday 02 Jun 2005 20:24, Taybin Rutkin wrote:
> I'd really like to push a new release out, due to the osx 10.4 fix from
> sletz, and the lack of releases the past couple months.  Since no one
> commented on my last email about remaining issues, except for pointing to a
> patch which I'm not sure should be applied or not and can be held for
> later

About the patch, I beg to differ.
The bug is a real one, it has historically been discussed several times (not
just by me ;). Fixing it will solve a common problem that I think affects a
lot of people.
Basically, given a choice, I would always run Jack with this behaviour. I
don't want to be bothered that my system isn't good enough to keep up all the
time but I still want to run with the best possible settings.

I could even go so far as suggesting this should be the default. The hard
realtime that jack employs is to me more usable in a debugging environment.

Possibly the patch isn't done right, I can rework it if I get some feedback
what the issues are.

Regards,
Robert

> , I'll put out a release this weekend unless someone stops me. :)
>
> Taybin
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Jackit-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jackit-devel

--
http://spamatica.se/musicsite/


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release

Taybin Rutkin
In reply to this post by Taybin Rutkin
Could you repost the patch?

Taybin

-----Original Message-----
From: Robert Jonsson <[hidden email]>
Sent: Jun 2, 2005 3:11 PM
To: [hidden email], Taybin Rutkin <[hidden email]>
Cc: [hidden email]
Subject: Re: [Jackit-devel] Upcoming release

Hi,

On Thursday 02 Jun 2005 20:24, Taybin Rutkin wrote:
> I'd really like to push a new release out, due to the osx 10.4 fix from
> sletz, and the lack of releases the past couple months.  Since no one
> commented on my last email about remaining issues, except for pointing to a
> patch which I'm not sure should be applied or not and can be held for
> later

About the patch, I beg to differ.
The bug is a real one, it has historically been discussed several times (not
just by me ;). Fixing it will solve a common problem that I think affects a
lot of people.
Basically, given a choice, I would always run Jack with this behaviour. I
don't want to be bothered that my system isn't good enough to keep up all the
time but I still want to run with the best possible settings.

I could even go so far as suggesting this should be the default. The hard
realtime that jack employs is to me more usable in a debugging environment.

Possibly the patch isn't done right, I can rework it if I get some feedback
what the issues are.

Regards,
Robert

> , I'll put out a release this weekend unless someone stops me. :)
>
> Taybin
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Jackit-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jackit-devel

--
http://spamatica.se/musicsite/



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release

Karsten Wiese
In reply to this post by Taybin Rutkin
Am Donnerstag, 2. Juni 2005 20:24 schrieb Taybin Rutkin:
> I'd really like to push a new release out, due to the osx 10.4 fix from
sletz, and the lack of releases the past couple months.  Since no one
commented on my last email about remaining issues, except for pointing to a
patch which I'm not sure should be applied or not and can be held for later,
I'll put out a release this weekend unless someone stops me. :)

Hi Taybin

The attached patch lets jackd quit gracefully, when my usb sound card's usb or
power cable is unplugged.
Without it, jackd has to be sent control+c then.
I also think its generally correct as it passes the error status to the
caller, which does not happen for the nframes == 0 case without it.

thanks,
Karsten

alsa_driver.c-driver_failed.patch (644 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release

Rui Nuno Capela
In reply to this post by rj (Bugzilla)
> Hi,

>
> On Thursday 02 Jun 2005 20:24, Taybin Rutkin wrote:
>> I'd really like to push a new release out, due to the osx 10.4 fix from
>> sletz, and the lack of releases the past couple months.  Since no one
>> commented on my last email about remaining issues, except for pointing
>> to a patch which I'm not sure should be applied or not and can be held
>> for later
>
> About the patch, I beg to differ.
> The bug is a real one, it has historically been discussed several times
> (not just by me ;). Fixing it will solve a common problem that I think
> affects a lot of people.
> Basically, given a choice, I would always run Jack with this behaviour. I
> don't want to be bothered that my system isn't good enough to keep up all
> the time but I still want to run with the best possible settings.
>
> I could even go so far as suggesting this should be the default. The hard
> realtime that jack employs is to me more usable in a debugging
> environment.
>
> Possibly the patch isn't done right, I can rework it if I get some
> feedback what the issues are.
>
Is this one the patch you're talking about?

Cheers.
--
rncbc aka Rui Nuno Capela
[hidden email]

jack-0.99.74-client_timeout.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release

Rui Nuno Capela
In reply to this post by Karsten Wiese
Hi Taybin,

> I'd really like to push a new release out, due to the osx 10.4 fix from
> sletz, and the lack of releases the past couple months.  Since no one
> commented on my last email about remaining issues, except for pointing to
> a patch which I'm not sure should be applied or not and can be held for
> later, I'll put out a release this weekend unless someone stops me. :)
>

OK. I'll ask you to review this one too. Is a rather innocuous patch, that
only affects the usx2y backend, so to make some null-cycle warning message
posted on verbose mode only.

I could apply to cvs myself, but I'm affraid I'll be "slightly" offline
for the next couple of days, so probably there's the risk of missing this
weekend release.

Oh, and I'm also all thumbs up to Karsten's patch, the one about jackd
terminating gracefully when unplugging the usb/power of my US-224 :)

Please?
--
rncbc aka Rui Nuno Capela
[hidden email]

jack-0.99.74-usx2y_null_cycle.patch (545 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release

rj (Bugzilla)
In reply to this post by Rui Nuno Capela
Hi Rui,

On Friday 03 Jun 2005 10:24, Rui Nuno Capela wrote:

> > Hi,
> >
> > On Thursday 02 Jun 2005 20:24, Taybin Rutkin wrote:
> >> I'd really like to push a new release out, due to the osx 10.4 fix from
> >> sletz, and the lack of releases the past couple months.  Since no one
> >> commented on my last email about remaining issues, except for pointing
> >> to a patch which I'm not sure should be applied or not and can be held
> >> for later
> >
> > About the patch, I beg to differ.
> > The bug is a real one, it has historically been discussed several times
> > (not just by me ;). Fixing it will solve a common problem that I think
> > affects a lot of people.
> > Basically, given a choice, I would always run Jack with this behaviour. I
> > don't want to be bothered that my system isn't good enough to keep up all
> > the time but I still want to run with the best possible settings.
> >
> > I could even go so far as suggesting this should be the default. The hard
> > realtime that jack employs is to me more usable in a debugging
> > environment.
> >
> > Possibly the patch isn't done right, I can rework it if I get some
> > feedback what the issues are.
>
> Is this one the patch you're talking about?

I realize I should have explained abit more what I was talking about. ;-P

I think it's the same patch (the diff looks different but I didn't spot any
differences ;).
Here is the original message:
http://sourceforge.net/mailarchive/message.php?msg_id=11674219

The patch doesn't do much, it basically changes the behaviour so --timeout is
accepted when jack is run in realtime mode (-R).
The behaviour with current jack while running -R is that a client will always
be kicked if it takes too long in it's process.

Regards,
Robert


>
> Cheers.

--
http://spamatica.se/musicsite/


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release

rj (Bugzilla)
In reply to this post by Taybin Rutkin
On Thursday 02 Jun 2005 21:24, Taybin Rutkin wrote:
> Could you repost the patch?
>
> Taybin

Yup.
http://sourceforge.net/mailarchive/message.php?msg_id=11674219

It's in a different format in Rui's message.

Regards,
Robert


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release

Jack O'Quin-2
In reply to this post by Taybin Rutkin
Taybin Rutkin <[hidden email]> writes:

> I'd really like to push a new release out, due to the osx 10.4 fix
> from sletz, and the lack of releases the past couple months.  Since no
> one commented on my last email about remaining issues, except for
> pointing to a patch which I'm not sure should be applied or not and
> can be held for later, I'll put out a release this weekend unless
> someone stops me. :)

OK with me.  I don't have any pending work queued.
--
  joq


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

not kicking jack clients in -R mode. Was: Upcoming release

Benno Senoner
In reply to this post by rj (Bugzilla)
Thanks robert for the patch, this was so badly needed.
Applications like LinuxSampler are very dynamic in CPU usage and if you
push it to the limits
(eg you play a piano sample with high polyphony and pedal down)  it
often happens that jacks kicks it out.
Not very useful for live play. Of course using 100% of the CPU should be
avoided (eg by setting
polyphony limits that are adequate for the performance of your box) but
often those
CPU overload spikes are short and barely noticeable in the audio and
aren't that dramatic like
being kicked.
My take on kicking is that it makes sense to set a high timeout value
which is much higher
than the single fragment size. That way you still catch clients that
suck up all the CPU (eg due to a bug)
but still allow audio apps to continue after a CPU spike happened.
I'd say any sampler/synth that emits to jack wants that behaviour.

cheers,
Benno
http://www.linuxsampler.org



Robert Jonsson wrote:

>
>I realize I should have explained abit more what I was talking about. ;-P
>
>I think it's the same patch (the diff looks different but I didn't spot any
>differences ;).
>Here is the original message:
>http://sourceforge.net/mailarchive/message.php?msg_id=11674219
>
>The patch doesn't do much, it basically changes the behaviour so --timeout is
>accepted when jack is run in realtime mode (-R).
>The behaviour with current jack while running -R is that a client will always
>be kicked if it takes too long in it's process.
>
>Regards,
>Robert
>
>
>  
>
>>Cheers.
>>    
>>
>
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release

Rui Nuno Capela
In reply to this post by rj (Bugzilla)
Robert,

>> >
>> > Possibly the patch isn't done right, I can rework it if I get some
>> > feedback what the issues are.
>>
>> Is this one the patch you're talking about?
>
> I realize I should have explained abit more what I was talking
> about. ;-P
>
> I think it's the same patch (the diff looks different but I didn't spot
> any differences ;).
> Here is the original message:
> http://sourceforge.net/mailarchive/message.php?msg_id=11674219
>

OK. It is the same patch, but mine is in unified format (-u). Ah, I've
touched the comment text, but that's all.


> The patch doesn't do much, it basically changes the behaviour so
> --timeout is accepted when jack is run in realtime mode (-R).
> The behaviour with current jack while running -R is that a client will
> always be kicked if it takes too long in it's process.
>

I have this patch applied on my own rigs, ever since your original post,
so it should be OK :)

Cheers.
--
rncbc aka Rui Nuno Capela
[hidden email]



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release

Jack O'Quin-2
In reply to this post by Taybin Rutkin
Taybin Rutkin <[hidden email]> writes:

> I'd really like to push a new release out, due to the osx 10.4 fix
> from sletz, and the lack of releases the past couple months.  Since no
> one commented on my last email about remaining issues, except for
> pointing to a patch which I'm not sure should be applied or not and
> can be held for later, I'll put out a release this weekend unless
> someone stops me. :)

I believe there was a transport bug reported that was apparently a
regression from 0.99.0.  I can't find the e-mail about it right now.
--
  joq


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release

Florian Paul Schmidt-2
On Fri, 03 Jun 2005 23:43:14 -0500
"Jack O'Quin" <[hidden email]> wrote:

> Taybin Rutkin <[hidden email]> writes:
>
> > I'd really like to push a new release out, due to the osx 10.4 fix
> > from sletz, and the lack of releases the past couple months.  Since no
> > one commented on my last email about remaining issues, except for
> > pointing to a patch which I'm not sure should be applied or not and
> > can be held for later, I'll put out a release this weekend unless
> > someone stops me. :)
>
> I believe there was a transport bug reported that was apparently a
> regression from 0.99.0.  I can't find the e-mail about it right now.

Do you mean the problem that a transport client will get state ==
rolling and transport frame == 0 in two consecutive process callbacks
after starting the transport?

I file a bug report for reference:

http://jackit.sourceforge.net/mantis/view.php?id=65

Also i do not think (after taking a look at the source) that this issue
is really resolved ("jack_get_current_transport_frame() returns bad
values"):

http://jackit.sourceforge.net/mantis/view.php?id=61

This code snippet from 0.99.72 shows that the DLL code is not used for
it:

jack_nframes_t
jack_get_current_transport_frame (const jack_client_t *client)
{
        jack_position_t position;
        float usecs;
        jack_nframes_t elapsed;
        jack_transport_state_t tstate;

        /* get the current transport position information.
           this is thread-safe and atomic with respect
           to the structure contents.
        */

        tstate = jack_transport_query (client, &position);

        if (tstate != JackTransportRolling) {
                return position.frame;
        }

        /* compute the elapsed usecs then audio frames since
           the transport info was last updated
        */

        usecs = jack_get_microseconds() - position.usecs;
        elapsed = (jack_nframes_t) floor ((((float) position.frame_rate)
                                           / 1000000.0f) * usecs);

        /* return the estimated transport frame position
         */

        return position.frame + elapsed;
}

This looks to me very much like the old jack_frame_time implementation.
Dunno how to fix this though (it would involve atomically reading the
last transport frame AND the jack_frame_time)..

Flo

--
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release

Fons Adriaensen
On Sat, Jun 04, 2005 at 01:12:21PM +0200, Florian Schmidt wrote:

> This code snippet from 0.99.72 shows that the DLL code is not used for
> it:
>
> jack_nframes_t
> jack_get_current_transport_frame (const jack_client_t *client)
> {
>         jack_position_t position;
>         float usecs;
>         jack_nframes_t elapsed;
>         jack_transport_state_t tstate;
>
>         /* get the current transport position information.
>            this is thread-safe and atomic with respect
>            to the structure contents.
>         */
>
>         tstate = jack_transport_query (client, &position);
>
>         if (tstate != JackTransportRolling) {
>                 return position.frame;
>         }
>
>         /* compute the elapsed usecs then audio frames since
>            the transport info was last updated
>         */
>
>         usecs = jack_get_microseconds() - position.usecs;
>         elapsed = (jack_nframes_t) floor ((((float) position.frame_rate)
>                                            / 1000000.0f) * usecs);
>
>         /* return the estimated transport frame position
>          */
>
>         return position.frame + elapsed;
> }
>
> This looks to me very much like the old jack_frame_time implementation.
> Dunno how to fix this though (it would involve atomically reading the
> last transport frame AND the jack_frame_time)..

AFAICS, the value we want here is

  position.frame + (jack_frame_time() - jack_last_frame_time())

The new API I've working one for some time will give you the value in ()
in a single call. It's the difference between 'now' and the smoothed time
of the interrupt that triggered the current process cycle.
This value can be added to any timescale that runs at the same speed as
the HW, e.g. transport position. There is no need to re-implement the
same functionality, except for other time scales.

One of the reasons why this API proposal is delayed is that I'd like to
have a *single* transfer of *all* transport and time information between
jackd and a client's space. This would mean a lot of changes, and I want
to be sure nothing is broken.

--
FA


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release

Lee Revell
In reply to this post by Karsten Wiese
On Thu, 2005-06-02 at 23:51 +0200, Karsten Wiese wrote:
> +       if (wait_status < 0)
> +               return -1;              /* driver failed */
> +
>         if (nframes == 0) {
>  
>                 /* we detected an xrun and restarted: notify

You should probably use unlikely() for both of these.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release

Florian Paul Schmidt-2
In reply to this post by Fons Adriaensen
On Sat, 4 Jun 2005 14:37:12 +0200
fons adriaensen <[hidden email]> wrote:

> AFAICS, the value we want here is
>
>   position.frame + (jack_frame_time() - jack_last_frame_time())
>
> The new API I've working one for some time will give you the value in ()
> in a single call. It's the difference between 'now' and the smoothed time
> of the interrupt that triggered the current process cycle.
> This value can be added to any timescale that runs at the same speed as
> the HW, e.g. transport position. There is no need to re-implement the
> same functionality, except for other time scales.
>
> One of the reasons why this API proposal is delayed is that I'd like to
> have a *single* transfer of *all* transport and time information between
> jackd and a client's space. This would mean a lot of changes, and I want
> to be sure nothing is broken.

I agree though (for what it's worth) that this is a good thing (tm),
especially as having *all* transport and time information available with
a single "atomic" function will automatically rid us of the remaining
atomicity issue with your current api proposal wrt to the
jack_get_current_transport_frame()).

Flo

--
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release

Alfons Adriaensen
On Tue, Jun 07, 2005 at 12:31:37PM +0200, Florian Schmidt wrote:

> On Sat, 4 Jun 2005 14:37:12 +0200
> fons adriaensen <[hidden email]> wrote:
>
> > AFAICS, the value we want here is
> >
> >   position.frame + (jack_frame_time() - jack_last_frame_time())
> >
> > The new API I've working one for some time will give you the value in ()
> > in a single call. It's the difference between 'now' and the smoothed time
> > of the interrupt that triggered the current process cycle.
> > This value can be added to any timescale that runs at the same speed as
> > the HW, e.g. transport position. There is no need to re-implement the
> > same functionality, except for other time scales.
> >
> > One of the reasons why this API proposal is delayed is that I'd like to
> > have a *single* transfer of *all* transport and time information between
> > jackd and a client's space. This would mean a lot of changes, and I want
> > to be sure nothing is broken.
>
> I agree though (for what it's worth) that this is a good thing (tm),
> especially as having *all* transport and time information available with
> a single "atomic" function will automatically rid us of the remaining
> atomicity issue with your current api proposal wrt to the
> jack_get_current_transport_frame()).

Yes. Some more observations: (some may be controversial)

- AFAICS, the atomicity problem does not really exist. All the timing
and transport info is updated by jackd's main RT thread at the start
of a cycle. If the copy operation is ever interrupted, that means that
jackd has started a new cycle while a client was still busy with the
current one, i.e. there has been an xrun.
Those calls that refer to 'now' (e.g. jack_frame_time()) could be (and
probably will be) used in other places outside the process callback
to get a timestamp on received events, and then of course the copy could
be interrupted and needs to be guarded. But the timing and transport info
is not needed at that time - the only thing required is the current time
on a scale that jack understands, i.e. jack_get_microseconds().
These timestamps will end up in the process thread sooner or later (if not
they were useless to start with), and the conversion to frame or transport
time can be done there.
In other words, if the two operations of getting the time and converting
it to some practical time scale are separated in the API, there is never
any need to do the copy outside the process callback, and if it is done
only there, there is no real need to guard it as an interruption means
there is anothor much more urgent problem anyway. In fact, since the
info is in shared memory, there is no need to copy it, provided it is
used only by the process callback, and AFAICS, that is always possible.


- Transport is of no concern to jackd - it reads/writes frames from/to
the hardware, and for each period calls all clients in the proper order.
It does this regardless of transport state. In other words, the only
way jackd participates in the whole transport story is by providing the
means for clients to share a transport state, and it is never itself
affected by it.

- If transport is no more than a state shared between some clients that
are aware of it, there could easily be more than one transport state
in a jack system. I can imagine clients A and B sharing one transport
state, and C, D and E a second one. So the API for transport control
should allow for more than one to exist at any time, maybe adopting
the current global one as a 'default transport' that is created
by jackd rather than by a client, but that is otherwise just the
same as any other.

- Multiple tranport states could be just independent of each other,
but they also provide another way to look at the synchronisation
problem. Imagine you have a set of clients that share a transport
state, based on some time format, say a number of sequencers using
song position to talk to each other.
Now we add e.g. an SMPTE reader client. This client is in a
second transport group, together with the external device that
generates the SMPTE (and any others that use it). It would create
its own jack transport state as a master, and allow others to share
it. If now we want to sync the first group (the sequencers using
song position) to the SMPTE, there is no need for all of them to
understand anything about SMPTE. All you need is a 'synchroniser'
client that understands the two transports states, and slaves the
one to the other. So instead of having ad-hoc solutions in many
clients, this opens the way to a systematic and modular approach.


(I warned you that some of this could be controversial :-)

--
FA
















-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel