[gmpi] Re: Topic 6: Time representation
- From: "Silver Blade" <lists@xxxxxxxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Sat, 10 May 2003 17:46:30 +0100
> > Why not? I usually let background services in Windows 2000 have priority
> > over foreground stuff, since it gives ASIO and other drivers a bit more
> > life. So I'm pretty sure that thread priorities are applicable in
Windows.
>
> As far as know ! there is nothing precise below 1ms under windows. Even a
> MultimediaTimer cannot warrant the one ms strictly between 2 calls.
Because
> some system task (especially driver) can lock the CPU during a indefinite
> time. Even the ASIO Driver callback is an event which can be delayed by
the
> system for whatever (display an info box for example) and cut your sound,
> and just because a PC cannot provide a precise 1ms timer by feature.
>
> In the years 1998 upto 2000 i remember some audio manufacturer were using
> MultimediaTimer or whatever timer connected on the PIT (programmable
> interrupt timer of the PC) to compute time and manage M.I.D.I. Sequencer
and
> the MIDI was synchronize on this PIT and the AUDIO stream was depending of
> course of the audio board clock . But the PIT when programmed for 1000
calls
> per second induce a 9ms derivation per minutes (it's due to the base
> frequency of the pit) . So many clients were complaining about
> un-synchronization between audio and MIDI after 3 or 5 minutes... Why !?
> Just because there was 2 clocks. Now they just use timer to push MIDI
Event
> , but they get the time from the audio stream or from an external clock.
Well there are various people to blame for this:
1) The manufacturers of the hardware (motherboard / PIT chip), who obviously
didn't use a good component
2) The user of such hardware, for choosing that hardware to use in an audio
workstation
3) The authors of the software, who didn't account for the above
These days, it's all about compatibility. PC hardware is designed to be
compatible with other brands, and software to be compatible with other
software file formats etc.
This means you could have 2 PCs with completely different hardware brands
and still be able to run the same OS and programs on both.
As an example, I made a MIDI sequencer/tracker a while ago, and on most
computers it runs fine. On Windows 2000, there's a significant amount of
latency when playback begins, compared to Windows ME. This is because my
program sends a lot of MIDI messages. It's just how different Windows
versions work.
There is a fairly easy way to combat this clock drift, and that is to base
timings on the buffer-switches, rather than just by programming the
multimedia timers. And you have mentioned this - but it's still using more
than one clock.
What you can do is keep check of how long each buffer plays for, and when a
buffer-switch occurs, queue up the events to be played within the next
buffer "frame". So the first buffer-switch of playback would cause the next
buffer to be filled with audio data, while the current one is empty. Once
the empty buffer is passed to us for filling, we know that the first one we
filled is playing, so we then set the timer for the first MIDI event. When
the timer callback is called, we play the first event and any other events
due to occur at the same time, find the next event in the queue and set the
timer for that. Until there are no more left.
This probably doesn't make much sense, but the basic idea is that you only
queue up the events due to occur as the next buffer is being played. So, for
a buffer which is 10 ms long for example, you queue up the events due to
occur within the next 10 ms. Generally, this would be very slow, since you
need to keep seeking every 10 ms, sifting through every event, but there are
ways of speeding it up. I have created a small MIDI scheduler prototype that
is able to seek out a range of events from a database of 10,000 events or so
extremely quickly, by grouping events into blocks.
>
> > As MIDI data needs to be worked with more often than audio (MIDI data
> needs
> > to be sent at the time events should occur, while audio is serviced in
> > blocks), it makes perfect sense to have MIDI being processed in a higher
> > priority thread than the audio one.
>
> perfect sense !? personnally i never seen that, and i cannot imagine an
> audio station where the audio stream might be cut by a MIDI code reception
!
It's not a case of the audio stream cutting out, it's just so the
computer/OS knows that you want more attention given to the MIDI scheduler
rather than the rest of the application. High-priority threads are serviced
more often than other threads, so any fine-timings can be done with them.
> synchronisation usually means that there is one master clock and slave one
.
> we cannot here talk about 2 different clocks.
Well with MIDI and audio being 2 different clocks, I've already said how it
can be done.
Where MIDI timing is based on a combination of audio buffer-switches and a
multimedia timer, the audio device must therefore be the master clock, since
the MIDI events are being slaved to that.
> imagine if only one popular Native platforms was working 100% ! this would
> be great
> ! isn't it ! :-))
So you think nobody should be allowed choice, and we should all use the same
computers and software?
I'm sure one day we'll be able to seamlessly have audio/MIDI hardware
devices sync. together in a computer, possibly have dedicated programmable
DSP chips and other nice stuff. It'd be nice to just be able to tell
hardware to do something at a particular time without having to manually set
up timers, and also be able to send an audio buffer to some DSP chip/memory,
have it processed there and sent back to the computer's memory, without the
main CPU having to worry about it.
Wait - isn't that what multiprocessor systems do?!
Still, you could always set up additional boxes and make your own DSP
farm...
-SB
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
