On Thu, 2005-07-14 at 01:06 +0200, fons adriaensen wrote:
> Agreed 100%. I just wonder about the availability of the required
> chip on mainstream motherboards. My machine (2 years old now) doesn't
> have it, as far as I'm able to find out. Does anyone have more
> visibility on this ?
>
I guess
On Wed, 2005-07-13 at 16:06, fons adriaensen wrote:
> [ Fernando Lopez-Lezcano ]
>
> > So, worst case scheduling would seem to me to be around 0.32 msec (ie: I
> > want the message to be sent at time t+/-320 usec).
>
> If you want jitter-free MIDI clock, that is absolutely correct. OTOH,
> I oft
[ Fernando Lopez-Lezcano ]
> So, worst case scheduling would seem to me to be around 0.32 msec (ie: I
> want the message to be sent at time t+/-320 usec).
If you want jitter-free MIDI clock, that is absolutely correct. OTOH,
I often wondered why MIDI interfaces are not designed to work in the
sa
On Wed, 2005-07-13 at 18:17 -0400, Eric Dantan Rzewnicki wrote:
> On Wed, Jul 13, 2005 at 02:20:20PM -0400, Lee Revell wrote:
> > On Wed, 2005-07-13 at 13:52 -0400, Lee Revell wrote:
> > > On Wed, 2005-07-13 at 13:42 -0400, Eric Dantan Rzewnicki wrote:
> > > > > > What is driving the kernel-devs to
Aha, thanks Lee and Paul, that explains that!
Iain.
Lee Revell wrote:
On Wed, 2005-07-13 at 12:12 -0700, Iain Duncan wrote:
In realtime critical applications people prefer RTLinux or the RTAI extension
to the kernel for periods and scheduling latencies in the low microseconds
range (<30 mi
On Wed, Jul 13, 2005 at 03:22:42PM -0400, Paul Davis wrote:
> On Wed, 2005-07-13 at 12:12 -0700, Iain Duncan wrote:
> > > In realtime critical applications people prefer RTLinux or the RTAI
> > > extension
> > > to the kernel for periods and scheduling latencies in the low
> > > microseconds
>
On Wed, 2005-07-13 at 15:17, Eric Dantan Rzewnicki wrote:
> On Wed, Jul 13, 2005 at 02:20:20PM -0400, Lee Revell wrote:
> > On Wed, 2005-07-13 at 13:52 -0400, Lee Revell wrote:
> > > On Wed, 2005-07-13 at 13:42 -0400, Eric Dantan Rzewnicki wrote:
> > > > > > What is driving the kernel-devs to regre
On Wed, 2005-07-13 at 18:20 -0400, Paul Davis wrote:
> > I suppose to make everyone happy this should be runtime configurable.
> > Incorporating which would be quite a task :)
>
> no, to make everyone happy we need the High Res Timer patch. that avoids
> the stupidity of a fixed HZ, which is so ea
> I suppose to make everyone happy this should be runtime configurable.
> Incorporating which would be quite a task :)
no, to make everyone happy we need the High Res Timer patch. that avoids
the stupidity of a fixed HZ, which is so early '90s that its
embarrassing.
--p
On Wed, Jul 13, 2005 at 02:20:20PM -0400, Lee Revell wrote:
> On Wed, 2005-07-13 at 13:52 -0400, Lee Revell wrote:
> > On Wed, 2005-07-13 at 13:42 -0400, Eric Dantan Rzewnicki wrote:
> > > > > What is driving the kernel-devs to regress on this issue?
> > > > Saving battery on laptops. The only per
On Wed, 13 Jul 2005 12:44:32 -0400
Eric Dantan Rzewnicki <[EMAIL PROTECTED]> wrote:
> I expected something like this. But, I guess my question was more, who
> is complaining about HZ=1024? To which I guess the answer would be
> everyone who is more concerned about throughput than latency. Though,
On Wed, 2005-07-13 at 10:27, Lee Revell wrote:
> On Wed, 2005-07-13 at 18:31 +0200, Florian Schmidt wrote:
> > On Wed, 13 Jul 2005 10:49:11 -0400
> > Eric Dantan Rzewnicki <[EMAIL PROTECTED]> wrote:
> >
> > > > Correct, it's not an issue for apps driven by hardware interrupts like
> > > > JACK, be
On Wed, 2005-07-13 at 12:12 -0700, Iain Duncan wrote:
> > In realtime critical applications people prefer RTLinux or the RTAI
> > extension
> > to the kernel for periods and scheduling latencies in the low microseconds
> > range (<30 microseconds worst case scheduling latency on recent x86
> >
Me too. It worked great on both my ancient laptop and my desktop, though
I did have to modprobe snd-usb-audio to get my usb midi box detected.
I've been raving about it to everyone. It also is incredibly easy to
customize.
jaromil wrote:
On Tue, Jun 14, 2005 at 09:33:45AM -0500, Andres Cabrer
On Wed, 2005-07-13 at 12:12 -0700, Iain Duncan wrote:
> > In realtime critical applications people prefer RTLinux or the RTAI
> > extension
> > to the kernel for periods and scheduling latencies in the low microseconds
> > range (<30 microseconds worst case scheduling latency on recent x86
> >
In realtime critical applications people prefer RTLinux or the RTAI extension
to the kernel for periods and scheduling latencies in the low microseconds
range (<30 microseconds worst case scheduling latency on recent x86
hardware).
I've often wondered about that. Why are those sorts of ker
On Wed, 2005-07-13 at 13:52 -0400, Lee Revell wrote:
> On Wed, 2005-07-13 at 13:42 -0400, Eric Dantan Rzewnicki wrote:
> > > > What is driving the kernel-devs to regress on this issue?
> > > Saving battery on laptops. The only performance numbers anyone posted
> > > indicated HZ=250 sped up a kern
On Wed, 2005-07-13 at 13:42 -0400, Eric Dantan Rzewnicki wrote:
> > > What is driving the kernel-devs to regress on this issue?
> > Saving battery on laptops. The only performance numbers anyone posted
> > indicated HZ=250 sped up a kernel compile on a 16 CPU machine (!) by
> > ~5%, and this was a
On Wed, Jul 13, 2005 at 01:01:03PM -0400, Lee Revell wrote:
> On Wed, 2005-07-13 at 10:49 -0400, Eric Dantan Rzewnicki wrote:
> > On Tue, Jul 12, 2005 at 07:34:07PM -0400, Lee Revell wrote:
> > > On Wed, 2005-07-13 at 01:03 +0200, Florian Schmidt wrote:
> > > > Some semieducated blabbering ahead (m
On Wed, 2005-07-13 at 18:31 +0200, Florian Schmidt wrote:
> On Wed, 13 Jul 2005 10:49:11 -0400
> Eric Dantan Rzewnicki <[EMAIL PROTECTED]> wrote:
>
> > > Correct, it's not an issue for apps driven by hardware interrupts like
> > > JACK, because the sound card consumes data at a constant rate. But
On Wed, 2005-07-13 at 10:49 -0400, Eric Dantan Rzewnicki wrote:
> On Tue, Jul 12, 2005 at 07:34:07PM -0400, Lee Revell wrote:
> > On Wed, 2005-07-13 at 01:03 +0200, Florian Schmidt wrote:
> > > Some semieducated blabbering ahead (might be all wrong):
> > > I think i once read that interrupt handlin
On Wed, Jul 13, 2005 at 06:31:21PM +0200, Florian Schmidt wrote:
> On Wed, 13 Jul 2005 10:49:11 -0400
> Eric Dantan Rzewnicki <[EMAIL PROTECTED]> wrote:
> > > Correct, it's not an issue for apps driven by hardware interrupts like
> > > JACK, because the sound card consumes data at a constant rate.
Am Dienstag, 12. Juli 2005 21:53 schrieb Iain Duncan:
> That sounds like it would be useful for more than just audio, ie
> robotics, any embedded linux apps, etc.
>
In realtime critical applications people prefer RTLinux or the RTAI extension
to the kernel for periods and scheduling latencies in th
On Wed, 13 Jul 2005 10:49:11 -0400
Eric Dantan Rzewnicki <[EMAIL PROTECTED]> wrote:
> > Correct, it's not an issue for apps driven by hardware interrupts like
> > JACK, because the sound card consumes data at a constant rate. But for
> > MIDI or video where you have to periodically push data to t
On Tue, Jul 12, 2005 at 07:34:07PM -0400, Lee Revell wrote:
> On Wed, 2005-07-13 at 01:03 +0200, Florian Schmidt wrote:
> > Some semieducated blabbering ahead (might be all wrong):
> > I think i once read that interrupt handling "short circuits" the linux
> > scheduler (in the sense that not only a
On Wed, Jul 13, 2005 at 09:24:29 -0400, Brett McCoy wrote:
> Steve Harris wrote:
>
> >>Even if I am not using them all? I calculate I had maybe 12 - 15
> >>actually allocated ( will try to verify this tonight when I am back in
> >>the studio )
> >
> >They still take resources, even if theres no
Steve Harris wrote:
Even if I am not using them all? I calculate I had maybe 12 - 15
actually allocated ( will try to verify this tonight when I am back in
the studio )
They still take resources, even if theres nothing connected to them. As
Paul said, run jack_lsp to see how many there are.
On Wed, Jul 13, 2005 at 09:09:28 -0400, Brett McCoy wrote:
> Steve Harris wrote:
>
> >back of the envelope maths:
> >
> >soundcard ports are always assigned,
> >even if theres nothing connected: 22
> >hydrogen, 32*2: 64
> >ardour uses something
Steve Harris wrote:
back of the envelope maths:
soundcard ports are always assigned,
even if theres nothing connected: 22
hydrogen, 32*2: 64
ardour uses something like 4 per mono track,
plus 2 more?34
Paul Davis wrote:
On Wed, 2005-07-13 at 08:39 -0400, Brett McCoy wrote:
and then suddenly Ardour kept telling me that I was out of jack ports
and needed to reset jack. What is this? I had used maybe 4 stereo
ports total. My sound card has 12 in/10 out (but I was wasn't using
them), and Hyd
On Wed, Jul 13, 2005 at 08:39:53 -0400, Brett McCoy wrote:
> Last night I was setting up a session in Ardour. I had three tracks for
> keyboard parts that were from imported audio files, so they did not have
> any input ports set. I wanted to bring in drum parts from Hydrogen, and
> started se
On Wed, 2005-07-13 at 08:39 -0400, Brett McCoy wrote:
> and then suddenly Ardour kept telling me that I was out of jack ports
> and needed to reset jack. What is this? I had used maybe 4 stereo
> ports total. My sound card has 12 in/10 out (but I was wasn't using
> them), and Hydrogen present
Last night I was setting up a session in Ardour. I had three tracks for
keyboard parts that were from imported audio files, so they did not have
any input ports set. I wanted to bring in drum parts from Hydrogen, and
started setting up tracks to correspond with the tracks I was using in
Hydro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Jun 14, 2005 at 09:33:45AM -0500, Andres Cabrera wrote:
> I've also tried dynebolic (www.dynebolic.org) and on the two systems
> I've tried works considerably better than agnula live and the suse live
> audio cd.
>
> Cheers,
> Andres
wow :)
34 matches
Mail list logo