headers
Jack O'Quin | 1 Dec 2004 01:34
Picon

Re: Bug 44 (multiple servers)

Lee Revell <rlrevell <at> joe-job.com> writes:

> This bug can be resolved, since the CVS version supports multiple
> servers.
> 
> http://jackit.sourceforge.net/mantis/view.php?id=44

Right.

I plan to wait until the support is a little more *complete*.  :-)
--

-- 
  joq

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
Permalink | Reply | 0 comments |
headers
Jack O'Quin | 1 Dec 2004 01:45
Picon

Re: probably running under a kernel with capabilities disabled

Paul Davis <paul <at> linuxaudiosystems.com> writes:

> >jackstart: cannot get realtime capabilities, current capabilities are:
> >            =ep cap_setpcap-ep
> >     probably running under a kernel with capabilities disabled,
> >     a suitable kernel would have printed something like "=eip"
> >
> >What do I need to do to my 2.6.5 kernel?
> 
> you need the realtime LSM (Linux Security module). try 
> http://realtime-lsm.sf.net/
> 
> we need to do a better job of noting that jackstart is strictly
> intended for 2.4 kernels only.

Yes, the FAQ is a little out of date in that area.  I removed the
`allcaps' option from the latest realtime-lsm version.

But, I also fixed jackstart so it always tries to exec jackd even if
the capabilities appear not to be available.  So, with recent versions
of JACK, it works correctly anyway.
--

-- 
  joq

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jack O'Quin | 1 Dec 2004 01:47
Picon

Re: mantis fixed

Lee Revell <rlrevell <at> joe-job.com> writes:

> On Tue, 2004-11-30 at 23:47 +0000, Simon Jenkins wrote:
> > I finally successfully registered just after you posted that you had 
> > successfully
> > registered. I can still log in now, so whatever's wrong its not a 
> > problem with
> > very recent registrations. (Not one that I can replicate anyway).
> 
> Yeah it seems to work now.  I signed up for a new account which worked
> perfectly, then an hour later I got my password reset mail.  I still
> cannot believe I entered my password wrong twice, but it looks like user
> error plus a slow mail queue.

I've been seeing intermittent poor performance.  I imagine this comes
from SF overloading.  Taybin says it would probably work better on
another site.  That makes sense to me.
--

-- 
  joq

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
Permalink | Reply | 0 comments |
headers
Florian Schmidt | 1 Dec 2004 01:50
Picon
Gravatar

Re: IRC log re: rolling time

On Tue, 30 Nov 2004 21:08:02 +0100
Fons Adriaensen <fons.adriaensen <at> skynet.be> wrote:

> This seems to be the inverse to a problem I was working on some time ago,
> related to apps such as scsynth (SuperCollider's synthesizer engine) where
> you have to map system time (from the OSC commands) to JACK frames.

No, this is exactly the same problem (kinda sorta inaway ;)). See below.

> Let's start with (2).
> 
> Suppose you have t_0, the system time corresponding to the first
> frame of the current period. You can find t_n for frame n as
> t0 + n / sample_rate. This will *not*  always be monotonic when
> used in different periods, for two reasons: the jitter on t_0, and
> the error on the actual value of sample_rate (the latter is really
> quite harmless in practice).
> 
> One solution is to calculate the time for the first frame in the
> *next* cycle, t1, and use as t0 the value of t1 of the previous
> cycle. Compute t_n as t0 + n * (t1 - t0) / period_size. This is
> monotonic and continuous *by design*.

Hmm, actually jackd doesn't need to map from frame n -> time t, but
rather the other way around. The call in question is 

jack_nframes_t jack_frame_time(const jack_client_t *client);

The time t is the time of the calling of the function. It can be used by
clients to timestamp events which the client receives via some other
(Continue reading)

Permalink | Reply | 9 comments |
headers
Florian Schmidt | 1 Dec 2004 01:54
Picon
Gravatar

Re: jack USB low latency bug and progress (long)

On Tue, 30 Nov 2004 15:56:43 -0800
Mark Knecht <markknecht <at> gmail.com> wrote:

> Great. Thanks!
> 
> 
> On Tue, 30 Nov 2004 18:42:50 -0500, Lee Revell <rlrevell <at> joe-job.com> wrote:
> > On Tue, 2004-11-30 at 15:35 -0800, Mark Knecht wrote:
> > > Thanks. So the 2.6.10-rcx patch is against 2.6.9 from kernel.org?
> > >
> > 
> > Correct.  This should be the patching order:
> > 
> > http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.9.tar.bz2
> > http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.10-rc2.bz2
> > http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm3/2.6.10-rc2-mm3.bz2
> > http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm3-V0.7.31-15

btw: for all the lazy people i wrote a small script that downloads all
nessecary stuff and patches up a kernel with the realtime preemptive
patches. It's not always up to date with the very latest version, but
can be easily adapted. It also patches in the realtime lsm support. Find
it here:

http://www.affenbande.org/~tapas/RP-patch-script

It only downloads stuff if the nessecary tarballs/patches are not found
in the current dir.

Have fun (i just updated it to use 0.7.31-15)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lee Revell | 1 Dec 2004 03:03

Re: jack USB low latency bug and progress (long)

On Wed, 2004-12-01 at 01:54 +0100, Florian Schmidt wrote:
> > > http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.10-rc2-mm3-V0.7.31-15
> 
> btw: for all the lazy people i wrote a small script that downloads all
> nessecary stuff and patches up a kernel with the realtime preemptive
> patches. It's not always up to date with the very latest version, but
> can be easily adapted.

You could actually automate this completely.  There is only ever one
file (the latest version) in the
http://redhat.com/~mingo/realtime-preempt/ directory, you just grab the
file, extract the required kernel and -mm patch version from the
filename, and grab those.

Lee

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
Permalink | Reply | 0 comments |
headers
Alfons Adriaensen | 1 Dec 2004 15:15
Picon
Picon

Re: IRC log re: rolling time

On Wed, Dec 01, 2004 at 01:50:02AM +0100, Florian Schmidt wrote:
> On Tue, 30 Nov 2004 21:08:02 +0100
> Fons Adriaensen <fons.adriaensen <at> skynet.be> wrote:
> 
> > This seems to be the inverse to a problem I was working on some time ago,
> > related to apps such as scsynth (SuperCollider's synthesizer engine) where
> > you have to map system time (from the OSC commands) to JACK frames.
> 
> No, this is exactly the same problem (kinda sorta inaway ;)). See below.
> 
> > Let's start with (2).
> > 
> > Suppose you have t_0, the system time corresponding to the first
> > frame of the current period. You can find t_n for frame n as
> > t0 + n / sample_rate. This will *not*  always be monotonic when
> > used in different periods, for two reasons: the jitter on t_0, and
> > the error on the actual value of sample_rate (the latter is really
> > quite harmless in practice).
> > 
> > One solution is to calculate the time for the first frame in the
> > *next* cycle, t1, and use as t0 the value of t1 of the previous
> > cycle. Compute t_n as t0 + n * (t1 - t0) / period_size. This is
> > monotonic and continuous *by design*.
> 
> Hmm, actually jackd doesn't need to map from frame n -> time t, but
> rather the other way around. The call in question is 

This is still the same problem, provided some conditions are satisfied.
If you have a continuous and monotonic function n -> t then the inverse
function t -> n is also defined.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Paul Davis | 1 Dec 2004 15:31

Re: IRC log re: rolling time

>This would be a much more robust and flexible solution than the
>current one, and it's not more complicated at all. It's probably
>even simpler.

and its also almost identical with the design of the MTC slaving code
in ardour, which is an added plus :)

--p

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
Permalink | Reply | 2 comments |
headers
Florian Schmidt | 1 Dec 2004 15:37
Picon
Gravatar

Re: IRC log re: rolling time

On Wed, 1 Dec 2004 15:15:24 +0100
Alfons Adriaensen <fons.adriaensen <at> alcatel.be> wrote:

> > Hmm, actually jackd doesn't need to map from frame n -> time t, but
> > rather the other way around. The call in question is 
> 
> This is still the same problem, provided some conditions are satisfied.
> If you have a continuous and monotonic function n -> t then the inverse
> function t -> n is also defined.

true :) i need to ponder your proposed solution for a bit more

> > jack_nframes_t jack_frame_time(const jack_client_t *client);
> > 
> > The time t is the time of the calling of the function. It can be used by
> > clients to timestamp events which the client receives via some other
> > channel (for example incoming midi data, or user interactions).
> 
> Do you mean it can be called from outside the process() callback ?

exactly. jack_frame_time() can be called from outside the process
callback. As you correctly state it wouldn't be very useful otherwise.

[snip]

> This is similar to my scheme, except for two important details:
> 
> * The jitter is removed by the DLL. Lowpass filtering of the jitter will
>   be much more accurate in the long run that any test + correction you
>   could think off.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jack O'Quin | 1 Dec 2004 15:37
Picon

Re: IRC log re: rolling time

Alfons Adriaensen <fons.adriaensen <at> alcatel.be> writes:

> On Wed, Dec 01, 2004 at 01:50:02AM +0100, Florian Schmidt wrote:
>  
> > jack_nframes_t jack_frame_time(const jack_client_t *client);
> > 
> > The time t is the time of the calling of the function. It can be used by
> > clients to timestamp events which the client receives via some other
> > channel (for example incoming midi data, or user interactions).
> 
> Do you mean it can be called from outside the process() callback ?
> Otherwise it wouldn't be very useful. If I receive e.g. MIDI in a
> separete thread, then this thread should timestamp the events. If
> I have to wait until the process callback before I can get I timestamp
> then it's really a timestamp on the process callback, not on the event.

Yes, jack_frame_time() can be called either inside or outside of the
process callback.  But, Flo and Paul recently fixed some bugs in the
implementation.

> The function of jack_frame_time() should really be decomposed into
> two parts:
> 
> - get the current system time (whatever the source)
> - use the t -> n relation to find the corresponding frame,
> 
> for the simple reason that the second part is required separately
> anyway.

It is already done that way.
(Continue reading)

Permalink | Reply | 3 comments |

Gmane