On Thu, 2002-08-22 at 02:21, David Olofson wrote:
On Friday 16 August 2002 00.19, Bob Ham wrote:
On Thu, 2002-08-15 at 20:17, Paul Davis wrote:
[...timestamps...]
...and only make calls on those that are stamped now.
Except that removes the ability for the softsynth to accept events
in
Martijn Sipkema wrote:
I find that for sending MIDI to an external device, resolution = RTC
Hz works very well. It is a problem that a realtime audio thread
'suffocates' a RTC thread if low-latency is required, and only one
processor available. It's very hard to find a clean solution in
[...]
User space MIDI scheduling should run at high rt priority. If scheduling
MIDI events is not done at a higher priority than the audio processing
then it will in general suffer jitter at the size of the audio interrupt
period.
Jitter amounting to the length of time the audio cycle takes
Paul Davis ([EMAIL PROTECTED]):
none of this, alas, addresses the more fundamental question of how to
do the timing correctly. without something like the hard-timer patch,
its more or less impossible to do MIDI sequencing correctly under
linux. of course, you can do it well enough with
Paul Davis wrote:
none of this, alas, addresses the more fundamental question of how to
do the timing correctly. without something like the hard-timer patch,
its more or less impossible to do MIDI sequencing correctly under
linux. of course, you can do it well enough with existing
mechanisms,
none of this, alas, addresses the more fundamental question of how to
do the timing correctly. without something like the hard-timer patch,
its more or less impossible to do MIDI sequencing correctly under
linux. of course, you can do it well enough with existing
mechanisms, but the reason
I agree, however HZ=1000 should be usable for MIDI even without patches
for improved scheduling. I believe HZ=1000 is in 2.5?
its usable, but its still not correct.
right now, you can use RTC Hz = 1024 for the same effect, though that
is slightly even less correct.
--p
I find that for sending MIDI to an external device, resolution = RTC
Hz works very well. It is a problem that a realtime audio thread
'suffocates' a RTC thread if low-latency is required, and only one
processor available. It's very hard to find a clean solution in this
why not just run the RTC
for DirectMusic API - synching ASIO with DirectMusic must be a pain in someone's ass).
-Mikko
-Original Message-
From: ext Paul Davis [mailto:[EMAIL PROTECTED]]
Sent: 16. August 2002 17:35
To: [EMAIL PROTECTED]
Subject: Re: [linux-audio-dev] midi events in jack callback (was:
Reborn
I find that for sending MIDI to an external device, resolution = RTC
Hz works very well. It is a problem that a realtime audio thread
'suffocates' a RTC thread if low-latency is required, and only one
processor available. It's very hard to find a clean solution in this
case, but firm timers
So we need something which handles the timing like the DirectMusic(tm) in
the Linux kernel.
I would prefer not to have this in the kernel. If the kernel provides
accurate
scheduling and CLOCK_MONOTONIC then I think this can and should
be done from user-space. A driver should be able to read
On Fri, 16 Aug 2002 09:40:01 -0400
Paul Davis [EMAIL PROTECTED] wrote:
I sent a mail about this to the alsa-dev list, but didnt really get an
useful
answer.
I ran into the following problem when running my sequencer and my
sofsynth
together. Using ALSA sequencer, I can set a timestamp to the
Paul Davis wrote:
I find that for sending MIDI to an external device, resolution = RTC
Hz works very well. It is a problem that a realtime audio thread
'suffocates' a RTC thread if low-latency is required, and only one
processor available. It's very hard to find a clean solution in this
why not
Paul Davis ([EMAIL PROTECTED]):
What do you think the solution is? [...]
the hard-timers patch or something like it needs to go into the
kernel.
Thanks for clarifying.
ardour apparently outputs MIDI clock sync. [...]
no, it outputs MIDI Time Code, which is an entirely different
We know that the ideal way of doing this is having both the sequencer
and the softsynth access to the same exact clock for reference, then
having the audio app a predefined delay in time consisting of the
fragment size. After that it's a simple matter of taking the current
time before mixing a
using my drum machine or hard disk recorder as the clock source.
these devices provide a very low resolution clock, and it can't be
used to schedule MIDI data, only to provide a low resolution
positional reference.
24ppq is fine when your sequencer only schedules notes on 24ppq
Paul Davis wrote:
I find that for sending MIDI to an external device, resolution = RTC
Hz works very well. It is a problem that a realtime audio thread
'suffocates' a RTC thread if low-latency is required, and only one
processor available. It's very hard to find a clean solution in this
why not
On Fri, Aug 16, 2002 at 02:22:35PM -0400, Paul Davis wrote:
(cut)
2) is cheap, the patch exists, and we should consider promoting it as
widely as the low latency patches.
(cut)
Ok, let the lobbying begin :)
v
Paul Davis wrote:
Paul Davis wrote:
I find that for sending MIDI to an external device, resolution = RTC
Hz works very well. It is a problem that a realtime audio thread
'suffocates' a RTC thread if low-latency is required, and only one
processor available. It's very hard to find a clean
On Fri, 16 Aug 2002 14:14:02 -0400
Paul Davis [EMAIL PROTECTED] wrote:
We know that the ideal way of doing this is having both the
sequencer and the softsynth access to the same exact clock for
reference, then having the audio app a predefined delay in time
consisting of the fragment size.
Forgive my ignorance, but are we referring to
http://sf.net/projects/high-res-timers/ by
any chance?
Regards,
Scott.
On 2002.08.17 05:54 Vincent Touquet wrote:
On Fri, Aug 16, 2002 at 02:22:35PM -0400, Paul Davis wrote:
(cut)
2) is cheap, the patch exists, and we should consider
On Wed, 2002-08-14 at 15:06, Paul Davis wrote:
On Wed, 2002-08-14 at 13:21, Paul Davis wrote:
a pull model (hey client: do this much work right now).
Should the this much work be constant? Ie, should I be dealing with
midi events (of which there may or may not be some) inside or outside
On Thu, 2002-08-15 at 20:17, Paul Davis wrote:
I was actually thinking of ignoring time-stamps except within the code
that sequences events. If my jack clients are given a midi event (eg,
noteon,) they should deal with it immediately. Same goes for their
despatches. Is this not what I
23 matches
Mail list logo
