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 ev
Martijn Sipkema wrote:
>> This
>> would not help make things simpler. It would also mean that a Sysex
>> or pitch/CC burst routed through can delay MIDI clocks because of the
>> limited bandwidth on the MIDI wire.
>
>Sysex can hurt timing for other events, but that's MIDI. MIDI clock (any
>MIDI r
> >MIDI through and any other 'immediate' type MIDI messages do
> >not need to be scheduled, they can be written to the interface
immediately.
>
> Yes, they could. It would however necessitate different input routes
> for 'immediate' and 'queued' events to the MIDI output handler.
The MIDI I/O AP
Martijn Sipkema wrote:
>> Another reason to run MIDI behind audio: task switching and the cache
>> invalidation it causes. If audio processing is interrupted 1024 times
>> per second, audio performance *will* degrade, even more if many Jack
>> clients (= separate processes) are involved.
>>
>> No
[...]
> >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 cy
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 solut
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 promo
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 fr
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 t
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
>So we need something which handles the timing like the DirectMusic(tm) in the
>Linux kernel.
not at all. we just need very accurate scheduling, which implies
either:
1) an incredibly high timer interrupt.
OR
2) interrupts when needed.
1) costs too much on most, if not all, hardw
>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 i
>> >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 24p
>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 mixi
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 dif
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
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 mi
> 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
C
> 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
the MROS and go
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] mid
>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
>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
>> 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 t
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
>mechanis
> >Haven't written anything using MIDI and JACK (or LADSPA), but would it be
poss
> >ible to have a such system as with Cubase where the softsynths are
plugins whi
> >ch receive time-stamped MIDI events (time-stamp is an offset from the
block be
> >ginning in samples).
Either this (use audio samp
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
>Haven't written anything using MIDI and JACK (or LADSPA), but would it be poss
>ible to have a such system as with Cubase where the softsynths are plugins whi
>ch receive time-stamped MIDI events (time-stamp is an offset from the block be
>ginning in samples). The MIDI-through events that come in
em.
-Mikko
> -Original Message-
> From: ext Bob Ham [mailto:[EMAIL PROTECTED]]
> Sent: 16. August 2002 1:20
> To: Linux Audio Development Mailing List
> Subject: Re: [linux-audio-dev] midi events in jack callback (was:
> Reborn)
>
>
> On Thu, 2002-08-15 at 20:17, Pau
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 wha
>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 b
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)
31 matches
Mail list logo
