At Tue, 13 Jul 2004 17:45:30 -0400,
Lee Revell wrote:
On Tue, 2004-07-13 at 17:29, Andrew Morton wrote:
Lee Revell [EMAIL PROTECTED] wrote:
Would this explain these? When running JACK with settings that need
sub-millisecond latencies, I get them when I generate any load at all on
At Wed, 14 Jul 2004 05:36:31 -0400,
Lee Revell wrote:
On Wed, 2004-07-14 at 04:51, Takashi Iwai wrote:
At Tue, 13 Jul 2004 17:45:30 -0400,
Lee Revell wrote:
On Tue, 2004-07-13 at 17:29, Andrew Morton wrote:
Lee Revell [EMAIL PROTECTED] wrote:
Would this explain these?
Jorge García wrote:
I think zlib does that,
I can't see anything about archiving files in zlib.h, it's only about
compressing data. But I just found this one :
http://www.feep.net/libtar
It looks very nice and simple. And it seems I could do on-the-fly FLAC
compression, while on-the-fly-writing
Hello,
[EMAIL PROTECTED] wrote:
And did you find RoseGarden and Ardour we're sync'd up tightly?
I have yet to find them REALLY syncing really tightly
what distro are you on? what versions of the software? what hardware?
Sorry for not replying earlier. We wanted to do some tests
We made some tests to get a more clear picture, and in fact we got
rather confused instead. I will just give you the results, without
Windows-Options-Sync-Align captured material with [ Capture Time ]
Recording from soft-synths or other sample-synced sources requires a
different post-capture
On Wednesday 14 Jul 2004 1:40 pm, Maarten de Boer wrote:
- jack configured at 44100 Hz [...]
* Alsa 1.0.5a
This combination won't work for synchronised MIDI and audio with
Rosegarden.
The ALSA PCM timer (which Rosegarden 0.9.8 uses by default when JACK
is running) miscalculates the
This combination won't work for synchronised MIDI and audio with
Rosegarden.
Really? It seems to have worked for us. What are the symptoms?
Hallo,
Dave Phillips hat gesagt: // Dave Phillips wrote:
Btw, where can I get Softwerk now ? Is there an announcement on the way ?
Huh, I thought, Softwark was on hold? Is there a new version?
Ciao
--
Frank Barknecht _ __footils.org__
Olivier Guilyardi wrote:
Jorge García wrote:
I think zlib does that,
I can't see anything about archiving files in zlib.h, it's only about
compressing data. But I just found this one :
http://www.feep.net/libtar
It looks very nice and simple. And it seems I could do on-the-fly FLAC
compression,
On Wednesday 14 Jul 2004 2:00 pm, Maarten de Boer wrote:
This combination won't work for synchronised MIDI and audio with
Rosegarden.
Really? It seems to have worked for us. What are the symptoms?
Rosegarden's transport runs too fast, by about 0.15 seconds per minute
of run time.
Chris
Hallo,
Dave Phillips hat gesagt: // Dave Phillips wrote:
Btw, where can I get Softwerk now ? Is there an announcement on the way ?
Huh, I thought, Softwark was on hold? Is there a new version?
ok, the word is out :)
dave asked me innocently about softwerk on the train from
paris-bordeaux. i
Takashi Iwai wrote:
Is it possible that I am simply pushing my hardware past its limits?
Keep in mind this is a 600Mhz C3 processor.
I think yes. 32 frames / 44.1kHz = 0.725 ms.
I don't think so, I think it's because the Linux scheduler (and kernel
in general) since it's not a RTOS
is
On Wed, 2004-07-14 at 06:48, Takashi Iwai wrote:
At Wed, 14 Jul 2004 05:36:31 -0400,
Lee Revell wrote:
On Wed, 2004-07-14 at 04:51, Takashi Iwai wrote:
At Tue, 13 Jul 2004 17:45:30 -0400,
Lee Revell wrote:
On Tue, 2004-07-13 at 17:29, Andrew Morton wrote:
Lee Revell
On Wed, 2004-07-14 at 10:52, Lee Revell wrote:
On Wed, 2004-07-14 at 06:48, Takashi Iwai wrote:
At Wed, 14 Jul 2004 05:36:31 -0400,
Lee Revell wrote:
On Wed, 2004-07-14 at 04:51, Takashi Iwai wrote:
At Tue, 13 Jul 2004 17:45:30 -0400,
Lee Revell wrote:
On Tue,
On Wed, 2004-07-14 at 06:26, Chris Cannam wrote:
The ALSA PCM timer (which Rosegarden 0.9.8 uses by default when JACK
is running) miscalculates the interrupt frequency at 44100:
http://sourceforge.net/mailarchive/message.php?msg_id=8855303
So, it happens only at 44100, right?
--
Florin
* Jeremy Hall [EMAIL PROTECTED] wrote:
I compiled this on SMP and when I enabled preempt in /proc/sys/kernel
commands worked for a few seconds, then the machine crashed. It
responded to pings but otherwise was dead in the water. When I
enabled voluntary preempt as well, the machine almost
* Ingo Molnar [EMAIL PROTECTED] wrote:
The note says that you should be able to switch from the four modes of
operation at will while the machine is running. Is that true?
it's true, it should work. This is probably a bug in the patch.
Investigating it.
found the bug and i've uploaded
On Sun, Jul 11, 2004 at 03:42:58AM -0700, Andrew Morton wrote:
We do not want to enable preempt for Fedora yet because it
breaks just too much stuff
What stuff?
just look over all the fix preempt stuff that got added to the kernel in
the last 6 months. Sometimes subtle sometimes less so.
On Sun, 11 Jul 2004, Andrew Morton wrote:
Arjan van de Ven [EMAIL PROTECTED] wrote:
On Sun, Jul 11, 2004 at 03:42:58AM -0700, Andrew Morton wrote:
We do not want to enable preempt for Fedora yet because it
breaks just too much stuff
What stuff?
just look over all the fix
On Sat, 10 Jul 2004 14:15:47 +0200
Florian Schmidt [EMAIL PROTECTED] wrote:
Hi, chiming in late. I experienced the same. When i booted into the patched kernel
voountary_preemption was on. But when i tried to turn on kernel_preemption, too, it
immeaditly crashed.. will try your new patch
On Sun, 2004-07-11 at 12:30 +0200, Ingo Molnar wrote:
the reason is difference in overhead (codesize, speed) and risks (driver
robustness). We do not want to enable preempt for Fedora yet because it
breaks just too much stuff and is too heavy. So we looked for a solution
that might work for a
On Sun, 11 Jul 2004, Arjan van de Ven wrote:
On Sun, Jul 11, 2004 at 03:42:58AM -0700, Andrew Morton wrote:
We do not want to enable preempt for Fedora yet because it
breaks just too much stuff
What stuff?
Looks like some of the voluntary preemption changes might need some
eyeballing
On Mon, 12 Jul 2004 14:32:22 +0200
Florian Schmidt [EMAIL PROTECTED] wrote:
produce the next period while another one is playing. But: No matter which 2.6.x
kernel i use i always can trigger xruns by either
1] many window manager ops [like rapid desktop wheeling in fluxbox]
2] compiling a
Andrew Ingo Molnar [EMAIL PROTECTED] wrote:
I took a look at latencies and indeed 2.6.7 is pretty bad -
latencies up to 50 msec (!) can be easily triggered using common
workloads, on fast 2GHz+ x86 system - even when using the fully
preemptible kernel!
Andrew What were those workloads?
At Mon, 12 Jul 2004 21:01:16 -0400,
Lee Revell wrote:
Note that this info because available because someone set
/proc/asound/*/*/xrun_debug. We need more people doing that.
-
This goes back to the need for ALSA documentation. Someone needs to
write some. This will probably require
Andrew Morton writes:
Paul Davis [EMAIL PROTECTED] wrote:
resierfs: yes, it's a problem. I fixed it multiple times in 2.4, but the
fixes ended up breaking the fs in subtle ways and I eventually gave up.
andrew, this is really helpful. should we conclude that until some
announcement from reiser
On Mon, Jul 12, 2004 at 05:08:44PM -0700, Andrew Morton wrote:
of code then it's pretty obvious what's happening. If the trace is due to
a long irq-off time then it will point up into the offending
local_irq_enable().
schedule should be called with irq enabled, and I noticed here it's not
On Tue, 2004-07-13 at 03:49, Takashi Iwai wrote:
At Mon, 12 Jul 2004 21:01:16 -0400,
Lee Revell wrote:
Note that this info because available because someone set
/proc/asound/*/*/xrun_debug. We need more people doing that.
-
This goes back to the need for ALSA documentation.
Andrea Arcangeli [EMAIL PROTECTED] wrote:
On Mon, Jul 12, 2004 at 05:08:44PM -0700, Andrew Morton wrote:
of code then it's pretty obvious what's happening. If the trace is due to
a long irq-off time then it will point up into the offending
local_irq_enable().
schedule should be called
On Tue, Jul 13, 2004 at 11:48:29AM -0700, Andrew Morton wrote:
sys_sched_yield() also calls schedule() with local interrupts disabled.
It's a bit grubby, but saves a few cycles. Nick and Ingo prefer it that way.
we can remove the irqs_disabled() check in might_sleep then, I'd like to
call
From: Bill Huey (hui) [EMAIL PROTECTED]
On Tue, Jul 13, 2004 at 01:09:28PM +0100, Martijn Sipkema wrote:
[...]
Please double-check that there are no priority inversion problems and that
the application is correctly setting the scheduling policy and that it is
mlocking everything
Andrea Arcangeli [EMAIL PROTECTED] wrote:
On Tue, Jul 13, 2004 at 11:48:29AM -0700, Andrew Morton wrote:
sys_sched_yield() also calls schedule() with local interrupts disabled.
It's a bit grubby, but saves a few cycles. Nick and Ingo prefer it that way.
we can remove the irqs_disabled()
At Mon, 12 Jul 2004 20:01:51 -0400,
Paul Davis wrote:
OK, thanks. The problem areas there are the timer-based route cache
flushing and reiserfs.
We can probably fix the route caceh thing by rescheduling the timer after
having handled 1000 routes or whatever, although I do wonder if this
On Tue, Jul 13, 2004 at 02:54:24PM -0700, Andrew Morton wrote:
Confused. Where do we call cond_resched() with local interrupts disabled?
there are a lot of cond_resched, we might be calling it with irq
disabled, nobody ever did a might_sleep in the fast path of
cond_resched. And even if nobody
Andrea Arcangeli [EMAIL PROTECTED] wrote:
Sleeping with local interrupts disabled is usually a bug, so we should
prefer to keep that check in might_sleep().
either it's _always_ a bug including for entry.S or sched_yield, or it's
_never_ a bug. I don't understand the usually.
If some
On Tue, Jul 13, 2004 at 03:25:32PM -0700, Andrew Morton wrote:
local_irq_disable();
fiddle with per-cpu stuff
function_which_calls_cond_resched();
fiddle with per-cpu stuff
local_irq_enable();
then we want might_sleep() to warn about the bug.
might_sleep
From: Bill Huey (hui) [EMAIL PROTECTED]
On Tue, Jul 13, 2004 at 11:44:59PM +0100, Martijn Sipkema wrote:
[...]
The worst case latency is the one that counts and that is the contended case. If
you could guarantee no contention then the worst case latency would be the
very fast uncontended
Andrea Arcangeli [EMAIL PROTECTED] wrote:
On Tue, Jul 13, 2004 at 03:25:32PM -0700, Andrew Morton wrote:
local_irq_disable();
fiddle with per-cpu stuff
function_which_calls_cond_resched();
fiddle with per-cpu stuff
local_irq_enable();
then we want might_sleep()
On Tue, Jul 13, 2004 at 03:44:48PM -0700, Andrew Morton wrote:
Yeah, I know. might_sleep() in cond_resched() makes sense.
What I'm doing is basically to replace all might_sleep with cond_resched
and then I add might_sleep in cond_resched. I also merged all
new might_sleep in Ingo's patch
Andrea Arcangeli [EMAIL PROTECTED] wrote:
What I'm doing is basically to replace all might_sleep with cond_resched
I cannot see a lot of point in that. They are semantically different
things and should look different in the source.
And it's currently OK to add a might_sleep() to (say) an
On Tue, Jul 13, 2004 at 04:06:28PM -0700, Andrew Morton wrote:
Andrea Arcangeli [EMAIL PROTECTED] wrote:
What I'm doing is basically to replace all might_sleep with cond_resched
I cannot see a lot of point in that. They are semantically different
things and should look different in the
Andrea Arcangeli [EMAIL PROTECTED] wrote:
And it's currently OK to add a might_sleep() to (say) an inline path which
is expended a zillion times because we know it'll go away for production
builds. If those things become cond_resched() calls instead, the code
increase will be permanent.
Andrea Arcangeli [EMAIL PROTECTED] wrote:
I'm missing where cond_resched is needed inside lock_kernel though,
Anywhere where we do lots of work inside lock_kernel(). Various ioctls and
ext3 journal recovery are instances.
On Tue, Jul 13, 2004 at 04:32:36PM -0700, Andrew Morton wrote:
OK.
cond_resched() is usually a waste of space with CONFIG_PREEMPT. It might
make sense to define a cond_resched_if_not_preempt thingy, which only does
things if !CONFIG_PREEMPT. We'd still need to use cond_resched() inside
Hi,
I am happy to announce the first release of WONDER.
The program WONDER (Wave field synthesis of new dimensions of
electronic music in realtime) is designed to provide an interface
between a wave field synthesis system and the software or hardware
composers and performers of electronic music
Greetings:
As promised, here's a set of test criteria used by Alan Belkin in his
1994 review of notation programs for the Macintosh. I hope that the
authors of Linux music notation software will consider this list against
the features of their own efforts.
I'm not interested in comparing
Hallo,
Marije Baalman hat gesagt: // Marije Baalman wrote:
I am happy to announce the first release of WONDER.
Congratulations! I'm eager to check this out -- although my speaker
count is too low.. :(
Ciao
--
Frank Barknecht _ __footils.org__
As mentioned briefly, Dave Phillips innocently asked me about SoftWerk
while we were riding on the train from Paris to Bordeaux last week. I
thought how hard could it be to get it working again? and thereby
hangs a tale (and a tail).
To cut a short story shorter:
correction to a minor build issue:
http://linuxaudiosystems.com/softwerk/softwerk-2.0.1.tar.bz2
Martijn Sipkema [EMAIL PROTECTED] writes:
(the lock-free ringbuffer is a special case since the only
synchronizing that is done, i.e. read/write access to an int, is
done by the processor. I'm not convinced that this will work on all
architectures)
I can't think of any architecture on which
50 matches
Mail list logo
