Sync Issues (was Re: External MIDI Sync using OSS/Free)

Sync Issues (was Re: External MIDI Sync using OSS/Free)

[Billy Biggs]

On Tue, 26 Oct 1999, Paul Barton-Davis wrote:

> >> advice #1: do not use /dev/sequencer, solution, use /dev/midi*
> >
> >  This is pretty useless IMHO.  My sequencer started off writing out
> >/dev/midi, and it was consistently off-sync.  Badly off sync.
> 
> did you open it O_NONBLOCK, and which kernel were you using ?

  I was using O_RDWR | O_NONBLOCK, under a 2.2 kernel.  I was trying to do
drumrolls, 16th notes, at 140bpm or 150bpm.  It was no good.

  Well, I recorded some songs using it, but I had to avoid playing too
many notes in rapid succession on any one track, and damned if I trigger
drums with it.

> personally, most of my current applications are so phase-locked to a
> soundcard DAC that i can get "perfect" sync timing from that. some
> applications (and MIDI-only sequencers are a very good example of
> them) are not like this, however, since they do no audio output :)

  One requirement for ttrk was that it be able to trigger samples on beat,
in sync with incomming MIDI.  This is a pain in the ass, since I have to
know exactly where in the audio output I am in order to do the prediction
correctly.  The clock on (at least the OSS) /dev/dsp is no good, since it
gives you no indication of when underruns occur.

  Damn annoying.

  I currently have ttrk setup to just 'turn on' the sample as soon as it
sees the corresponding MIDI sync tick.  It's no good for drum samples or
loops or anything, but I can trigger cheezy sci-fi samples and they don't
sound _too_ out of place.  Ugh.

> >  What about syncing multiple soundcards?  I've found this to be next to
> >impossible under thud using OSS.
> 
> as has been discussed here a number of times, this is far from
> trivial. clock rates from card to card, even the same brand, and even
> from (warm) day to (cold) day vary, so its not just a matter of
> finding a way to get them to all start at the same time. 

  Yes, it is a pain, but there should be a better hacked job at least of
doing it.  When I still had Windows around, Sonic Foundry ACID had no
trouble at least faking some sync between my two AudioPCI cards.  I can't
get it as good as they did. :/

  There should also be API support for it.  I hope to soon (within the
next year) get a soundcard that has multiple dsps inside it, for
outputting multi-track stuff.  I'm really worried about how much I'm going
to have to code myself though.....

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)

[Billy Biggs]

On Tue, 26 Oct 1999, Paul Barton-Davis wrote:

> >  I was using O_RDWR | O_NONBLOCK, under a 2.2 kernel.  I was trying to do
> >drumrolls, 16th notes, at 140bpm or 150bpm.  It was no good.
> 
> hmm. i should try some stuff like this myself, but i haven't written
> an audio sequencer yet :)

  I'm sorry, you have me confused.  This was using /dev/midi, only
outputting MIDI notes.

> let me just clarify one thing: so ttrk is an audio+MIDI sequencer ? it
> does output audio as well as MIDI (or just audio ?)

  ttrk is currently only useful as a MIDI sequencer, but it happily opens
all audio devices available and will attempt to play samples on beat.

>      * soundcard has N fragments "queued" in its hardware buffer by 
>        the driver
>      * you're about to assemble the audio data for the next fragment
>      * you check for MIDI data
>      * MIDI data is here - you decide to include sample X in the next
>        fragment (and future ones too, most likely, since most samples
>        last longer than the fragment size).
> 
> where is the timing problem ? i am sure i am missing something, given
> that my MIDI related work has been almost entirely MIDI-only.

  Here's one algorithm I tried to use for a while, you'll see the problem:

   - There are N fragments "queued" by the hardware buffer in the
     soundcard
   - I check to see if i'm at the start of a new beat, if I am then
     - If there are samples to play, start playing them in this fragment
     - If there are MIDI notes to play, queue them to be played at
       time per fragment * N in the future

  The sync problem comes from not getting swapped in enough such that
you'll send out the MIDI data at the instant that the audio out the
soundcard actually gets played.

  This all gets worse once you have to know more about the audio buffer
location, for example, when you're trying to sync to an external MIDI
source, and already have alot of error due to your estimates about the
external sync's tempo and your predicted next beat.

  These days, I'm using three threads.  One for midi, one for audio, and
one for the GUI.

> >  There should also be API support for it.  I hope to soon (within the
> >next year) get a soundcard that has multiple dsps inside it, for
> 
> do you really mean DSP's ? the only cards I know like this are things
> like the Creamware Pulsar and SCOPE, and the Yamaha DSP Factory. Linux
> support for these is not likely to be forthcoming (though I may write
> the drivers for Creamware).

  Drivers had better be forthcomming.  Yes, I'm talking about cards like
those, such as the Event Layla and Darla, etc.  Without them, it makes
Linux pretty useless as a multitrack platform...

  Well, at least pretty annoying.  Personally, I have two AudioPCI cards
and a dedicated MPU-401 card for MIDI.  Each of the AudioPCI cards have
two dsps, giving me four /dev/dsp devices.

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)

[Paul Barton-Davis]

>  Here's one algorithm I tried to use for a while, you'll see the problem:
>
>   - There are N fragments "queued" by the hardware buffer in the
>     soundcard
>   - I check to see if i'm at the start of a new beat, if I am then
>     - If there are samples to play, start playing them in this fragment
>     - If there are MIDI notes to play, queue them to be played at
>       time per fragment * N in the future
>
>  The sync problem comes from not getting swapped in enough such that
>you'll send out the MIDI data at the instant that the audio out the
>soundcard actually gets played.

right, and the (or at least, *a*) solution (used in SoftWerk) is easy:
don't do forward queuing of MIDI data in /dev/sequencer. just output
it at the right time yourself, along with the audio data. the swapping
in/out problem is a separate issue - you may need to mlock() some of
the critical data in place. 

[ as an aside: a pet peeve: very few linux systems these days ever
swap. they do paging all the time, but thats different, well, sort
of. ]

your time resolution will be dictated by the fragment size used by the
soundcard driver/soundcard h/w, and it will way better than the kernel
sequencer offers, since its based on the timer interrupt (20ms typically).

SoftWerk's problem is even more acute: because one MIDI track can
control another's output data (e.g. one track controls the volume for
another track's NoteOn messages), and because the tracks run at
different speeds and may not ever be in sync, it is *impossible* to
use any kernel sequencer for any useful work. why ? because until time
T arrives, its impossible to compute what should actually be
sent. this means that you can't queue anything in the kernel
sequencer: you just have to wait for the "tick" to come around, and
compute what MIDI data should be sent (if any) on that tick.

in SoftWerk's case, because it doesn't process audio data in any way,
I use sigitimer(2) to give me a periodic async signal every so often
(typically 20-100ms: its controllable in the UI). i use this to
measure the passage of time, and compute when a beat/tick is
happening.  soon, i will use the RTC with select(2), which will be
more accurate and permit much faster tempos than sigitimer can.

if SoftWerk *did* handle audio data (which i hope it never does!), it
could use the timing from the soundcard DAC (or ADC) to get much more
precise timing. in such a system, external MIDI clock would just be
used as a master sync for tempo - i.e. each interval between 2 MIDI
clocks byte represents 1/24 (is that right ?) of a 1/4 beat.  we can
measure the time interval, and continue on with that tempo for our
calculations until the time between two MIDI clock bytes
changes. meanwhile, all actual scheduling of MIDI output data would be
done from the timebase of the soundcard DAC.

well, that's my approach anyway.

>  These days, I'm using three threads.  One for midi, one for audio, and
>one for the GUI.

sounds about right, although given the low speed of MIDI data, and the
fact that you can really only sensibly check for it between processing
audio fragments, you might be able to get away with just two.

>  Drivers had better be forthcomming.  Yes, I'm talking about cards like
>those, such as the Event Layla and Darla, etc.  Without them, it makes
>Linux pretty useless as a multitrack platform...

the manufacturers of such cards don't have much of an interest in
Linux. i did a little work at AES to try to change that, but its going
to be a long uphill battle.

>  Well, at least pretty annoying.  Personally, I have two AudioPCI cards
>and a dedicated MPU-401 card for MIDI.  Each of the AudioPCI cards have
>two dsps, giving me four /dev/dsp devices.

if you had 2 4D-NX's, you'd have 64 openable (mono) channels for
playback (*)...  is that enough for you ? :))) total cost $78+postage,
plus you'd have two excellent MIDI interfaces as well.

(*) but just 4 mono channels for recording, sigh.

--p

Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)

[Benno Senoner]

On Tue, 26 Oct 1999, Billy Biggs wrote:
> On Tue, 26 Oct 1999, Paul Barton-Davis wrote:
>   I was using O_RDWR | O_NONBLOCK, under a 2.2 kernel.  I was trying to do
> drumrolls, 16th notes, at 140bpm or 150bpm.  It was no good.

hmmm, really strange:
I wrote a little util called mididelay, which writes a note-on MIDI message on
the midi-out port reads back the message and measures the delay.
Paul got about 1.1ms delay ( = MIDI wire speed = 3 bytes x 350usecs )
on his box:  soundcard 4DNx + ALSA drivers)
I got a bad 11ms on my SB AWE64, and that is because the AWE64 doesn't
have a TX irq and ad FIFO of only 2byte = driver wroks in polling mode
 bad response times + high CPU usage, that means
forget this card for outputting dense MIDI streams.

BTW: which card are you using ?

>   One requirement for ttrk was that it be able to trigger samples on beat,
> in sync with incomming MIDI.  This is a pain in the ass, since I have to
> know exactly where in the audio output I am in order to do the prediction
> correctly.  The clock on (at least the OSS) /dev/dsp is no good, since it
> gives you no indication of when underruns occur.

I'd suggest to use the raw /dev/dsp and the raw /dev/midi interface:
use 2 threads: higher pri for audio, lower pri for midi
use a small fragmentsize x fragmentnum ,
( for example 3 x 256bytes = 4.3ms audio buffer)
then use the PCM playing thread as timer source ( 1.45ms accuracy in this case)
and simply wakeup the MIDI thread (via fifos/semaphore/msgqueues etc) from
the audio theread when you want to send data to MIDI out.
When data comes from MIDI in, put this in a queue ( msgsnd() , or use shmem )
and let the audio thread react on this on the next fragment,
(if you need sample accurate MIDI/audio sync, that is another story .. ).

Do not forget to apply the lowlatency patches, or your timing will simply suck !
even an untuned IDE disk, when it reads/writes a small amount of data from/to
the disk, could cause 20-50ms delay in your app and this is very bad
for MIDI.
( see my tests , especially the non DMA ones = horrible  :-)   ) 

> 
>   Damn annoying.

I think our collective timing/latency annoyance will go away with kernel 2.4,
mainly thanks to Ingo for his excellent work !
:-)

> 
>   I currently have ttrk setup to just 'turn on' the sample as soon as it
> sees the corresponding MIDI sync tick.  It's no good for drum samples or
> loops or anything, but I can trigger cheezy sci-fi samples and they don't
> sound _too_ out of place.  Ugh.

That is the precise reason why we are trying to put toghether the
realtime multimedia API (provided that the kernel delivers good timing
out of the box = kernel 2.4).
No worries anymore, and the system will always choose the optimal
way to transfer data/provide timing information and minimize scheduling
overhead.

> 
> > >  What about syncing multiple soundcards?  I've found this to be next to
> > >impossible under thud using OSS.
> > 
> > as has been discussed here a number of times, this is far from
> > trivial. clock rates from card to card, even the same brand, and even
> > from (warm) day to (cold) day vary, so its not just a matter of
> > finding a way to get them to all start at the same time. 

yes, this is far from trivial, but we will try to provide some usable solution:
mainly activating the cards by using DSP_SET_TRIGGER (if supported,
otherwise it's a real pain),  to minimize starting delays,
and then use one of the soundcards as source (or alternatively other
timer sources), and put the remaining cards into a "slave" mode,
where you measure the sample differences in audio buffers, and
insert additional or drop samples to keep things in sync.

> 
>   Yes, it is a pain, but there should be a better hacked job at least of
> doing it.  When I still had Windows around, Sonic Foundry ACID had no
> trouble at least faking some sync between my two AudioPCI cards.  I can't
> get it as good as they did. :/

You will
> 
>   There should also be API support for it.  I hope to soon (within the
> next year) get a soundcard that has multiple dsps inside it, for
> outputting multi-track stuff.  I'm really worried about how much I'm going
> to have to code myself though.....

Agreed,
I hope that an usable API/engine shows up during the next 6-9months.

I tested the peroformace of most subsystems of linux (involved in realtime
multimedia), and it seems that it is ready for our highend requirements.

Benno.


> 
> --
> Billy Biggs                         vektor@div8.net
> http://www.div8.net/billy       wbiggs@uwaterloo.ca

Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)

[Billy Biggs]

Benno, you kick ass,

> >   I was using O_RDWR | O_NONBLOCK, under a 2.2 kernel.  I was trying to do
> > drumrolls, 16th notes, at 140bpm or 150bpm.  It was no good.
> 
> hmmm, really strange:
> I wrote a little util called mididelay, which writes a note-on MIDI message on
> the midi-out port reads back the message and measures the delay.

  Can I get a copy of this program?  Are you just using gettimeofday()
before and after, or are you using ptrace or some other hackery?

> BTW: which card are you using ?

  For MIDI I'm using a Roland MPU-IPC-T card.  MPU-401.

> >   One requirement for ttrk was that it be able to trigger samples on beat,
> 
> I'd suggest to use the raw /dev/dsp and the raw /dev/midi interface:
> [...]

  Thanks for your suggestions.  I'm hacking at it now...

> Do not forget to apply the lowlatency patches, or your timing will
> simply suck ! even an untuned IDE disk, when it reads/writes a small
> amount of data from/to the disk, could cause 20-50ms delay in your app
> and this is very bad for MIDI. ( see my tests , especially the non DMA
> ones = horrible :-)  )

  What lowlatency patches??  kernel patches??  That's just ugly.  Where
can I get them?

> > > >  What about syncing multiple soundcards?
> 
> yes, this is far from trivial, but we will try to provide some usable
> solution: mainly activating the cards by using DSP_SET_TRIGGER (if
> supported, otherwise it's a real pain), to minimize starting delays,
> and then use one of the soundcards as source (or alternatively other
> timer sources), and put the remaining cards into a "slave" mode, where
> you measure the sample differences in audio buffers, and insert
> additional or drop samples to keep things in sync.

  How can you tell if you've underrun under OSS?  Using ALSA, I guess you
can use it's time stuff to calculate if you've missed a frame, but even
that seems hacky.

  Do you just always use gettimeofday() math to keep track of how much
stuff you've written, and when skips have occured?

  I don't like using one dsp as the sync master since I always want to be
able to sync to something external, like MIDI.

  So, the problem becomes, how do you sync many soundcards and have it all
synced off external MIDI. :)

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)

[Paul Barton-Davis]

>  What lowlatency patches??  kernel patches??  That's just ugly.  Where
>can I get them?

not ugly! the kernel folks, well Ingo Molnar in particular, recognized
that the kernel wasn't well tuned for low latency requirements. Ingo
believes that his patches will be in kernel 2.4.

look at http://www.gardena.net/benno/linux/audio for more details.

>  How can you tell if you've underrun under OSS?  Using ALSA, I guess you
>can use it's time stuff to calculate if you've missed a frame, but even
>that seems hacky.

no, ALSA has an ioctl to tell you if had underruns or overruns. its
The Right Way (TM). OTOH, i haven't written any audio programs that
ever use it, because I write them so that if I did have an
{over,under}run, it would mean that some totally catastrophic has
happened. maybe i don't write the right kinds of applications :)

>  I don't like using one dsp as the sync master since I always want to be
>able to sync to something external, like MIDI.

if you mean MTC, this simply isn't accurate enough for syncing
soundcards. you can use MTC as a master clock for tempo, but between
MIDI clock messages you will still have to be prepared to do the
actual syncing of soundcards. Given that a MTC messages take on the
order of 1ms to arrive (!), its not a high-quality sync source.

so, i don't think you can "sync soundcards" from MIDI. You can use MTC
to help inform your own sense of the forward passage of time and to
dictate MIDI-related tempo, but thats not the same thing that Benno
was talking about.

--p

Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)

[Billy Biggs]

On Thu, 28 Oct 1999, Paul Barton-Davis wrote:

> no, ALSA has an ioctl to tell you if had underruns or overruns. its
> The Right Way (TM). OTOH, i haven't written any audio programs that
> ever use it, because I write them so that if I did have an
> {over,under}run, it would mean that some totally catastrophic has
> happened. maybe i don't write the right kinds of applications :)

  How can you get close to that?  Do you always set realtime priority?  I
get underruns happening when I move the mouse, depending on system load,
even when the app is setuid root.

  Am I unique in that my apps never seem to be able to keep up?

> >  I don't like using one dsp as the sync master since I always want to be
> >able to sync to something external, like MIDI.
> 
> if you mean MTC, this simply isn't accurate enough for syncing
> soundcards. [...]
> 
> so, i don't think you can "sync soundcards" from MIDI. You can use MTC
> to help inform your own sense of the forward passage of time and to
> dictate MIDI-related tempo, but thats not the same thing that Benno
> was talking about.

  Right, I was being confusing.

  I'm not actually talking about MTC, I'm talking about counting 24ppq
sync pulses and predicting pulses, keeping in sync with them as much as
possible.  Pretty bad.

  So, it is still ncessary to keep the soundcards in sync with each other,
then have some objective sense of where in time the audio buffer is such
that I can tell the card the right thing to play at the time.

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca

Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)

[Paul Barton-Davis]

In message <Pine.LNX.4.04.9910281054160.1115-100000@shell.dhp.com>you write:
>On Thu, 28 Oct 1999, Paul Barton-Davis wrote:
>
>> no, ALSA has an ioctl to tell you if had underruns or overruns. its
>> The Right Way (TM). OTOH, i haven't written any audio programs that
>> ever use it, because I write them so that if I did have an
>> {over,under}run, it would mean that some totally catastrophic has
>> happened. maybe i don't write the right kinds of applications :)
>
>  How can you get close to that?  Do you always set realtime priority?  I
>get underruns happening when I move the mouse, depending on system load,
>even when the app is setuid root.

*smile* you've got a hardware problem. i know this because i have too :)

when i had to switch (temporarily) from my Matrix G200 AGP video card
to an old ISA-based Diamond Speedstar, the performance of my audio
stuff has gone down the tubes. i can't do *anything* with X and hope
to not get dropouts. this never happened with the Matrox card, and i
am very confident that as soon as Matrox ships me a new one, the
problem will go away.

right now, my system is essentially useless for audio work unless you
avoid using X. totally useless. i can't even play WAV files without
*huge* dropouts, and thats on a *dual* PII-450 !

if i use a text console, things are peachy.

>  I'm not actually talking about MTC, I'm talking about counting 24ppq
>sync pulses and predicting pulses, keeping in sync with them as much as
>possible.  Pretty bad.
>
>  So, it is still ncessary to keep the soundcards in sync with each other,
>then have some objective sense of where in time the audio buffer is such
>that I can tell the card the right thing to play at the time.

either i'm just confused, or you are, or both :)

barring underruns, which (trust me) are a totally separate issue, you
*always* know where you are since you're the one generating the
fragments for the audio buffer. if you asked for 3 fragments, then
other than for the first audio-buffer's worth of stuff (and you
typically fill it with silence when you start to avoid this problem),
you know that when you are working on a particular fragment, there are
2 more ahead of you that have yet to be played.

if you want more precise timing than is implied the fragment size
(which might be in the range of 0.5-2ms), you will need to timestamp
the MIDI messages you receive using, gettimeofday() or a cycle
counter, and do a little math based on the sample rate you configured
the soundcard to use. this way, you can calculate the "exact" sample
that was playing (i.e. emerging on the audio side of a DAC someplace)
when the MIDI message was "received", and then, by knowing how many
fragments are still pending (a fixed number, barring underruns), you
can infer exactly when any output that arises from (or should be
synced to) the MIDI data should emerge.

its pretty simple, really :)

--p

Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)

[Benno Senoner]

On Thu, 28 Oct 1999, Billy Biggs wrote:
> Benno, you kick ass,

HEHE, thank you !
:-)

> 
> > >   I was using O_RDWR | O_NONBLOCK, under a 2.2 kernel.  I was trying to do
> > > drumrolls, 16th notes, at 140bpm or 150bpm.  It was no good.
> > 
> > hmmm, really strange:
> > I wrote a little util called mididelay, which writes a note-on MIDI message on
> > the midi-out port reads back the message and measures the delay.
> 
>   Can I get a copy of this program?  Are you just using gettimeofday()
> before and after, or are you using ptrace or some other hackery?

the mididelay-0.1 is here:  ( read the README)

http://www.gardena.net/benno/linux/mididelay-0.1.tgz

> 
> > BTW: which card are you using ?
> 
>   For MIDI I'm using a Roland MPU-IPC-T card.  MPU-401.

Jaroslav do you know if there are similar problems on this card with too little
MIDI TX/RX FIFO size  , and/or lack of an IRQ connected to it ?

> 
> > Do not forget to apply the lowlatency patches, or your timing will
> > simply suck ! even an untuned IDE disk, when it reads/writes a small
> > amount of data from/to the disk, could cause 20-50ms delay in your app
> > and this is very bad for MIDI. ( see my tests , especially the non DMA
> > ones = horrible :-)  )
> 
>   What lowlatency patches??  kernel patches??  That's just ugly.  Where
> can I get them?

http://www.gardena.net/benno/linux/audio

read the entire page carefully and look at the old tests too,
then you will realize why I'm so confident that Linux will be
one of the best performing multimedia OSes around.

kernel patch ugly ?
If somethinfg is broken, we have to fix it:
Actually Ingo made the 2.2.10-lowlatency patch as a "demo" what can be done
with Linux.  :-)  
He told me he will integrate the changes into 2.3.x which will become 2.4
that means , ultra-low latency (down to 2.1ms on a P133) for regular
processes running with SCHED_FIFO policy, without messing around with
modules running in kernel space which could crash your entire system in case
if there is a bug. ( = see DirectX = blue screen in case of driver crashes  :-)
 )


> 
> > > > >  What about syncing multiple soundcards?
> > 
> > yes, this is far from trivial, but we will try to provide some usable
> > solution: mainly activating the cards by using DSP_SET_TRIGGER (if
> > supported, otherwise it's a real pain), to minimize starting delays,
> > and then use one of the soundcards as source (or alternatively other
> > timer sources), and put the remaining cards into a "slave" mode, where
> > you measure the sample differences in audio buffers, and insert
> > additional or drop samples to keep things in sync.
> 
>   How can you tell if you've underrun under OSS?  Using ALSA, I guess you
> can use it's time stuff to calculate if you've missed a frame, but even
> that seems hacky.

DSP_GETOSPACE tells you the bytes left in the audio buffer,
but if you want only detect overrruns, just use the RDTSC pentium cyclecounter
and measure if the time between two subsequent write()s to /dev/dsp is
bigger than the time it takes to play the entire audio buffer.
(I used this method in my latencytest and it works fairly well)


> 
>   Do you just always use gettimeofday() math to keep track of how much
> stuff you've written, and when skips have occured?

you can use gettimeofday() too,
I made the code portable so that on x86 you can use RDTSC, on other
architectures you can use gettimeofday(), which is more than adquate
for these purposes (but I saved a few machine cycles (and avoided a syscall) by
using RDTSC. 
(I was testing pure scheduling performance, therefore I had to avoid any
syscalls, except the audio ones)

> 
>   I don't like using one dsp as the sync master since I always want to be
> able to sync to something external, like MIDI.
> 
>   So, the problem becomes, how do you sync many soundcards and have it all
> synced off external MIDI. :)

That is no problem too: just use the MIDI clock as source, and drop/insert
samples on all dsp devices if you detect any drift.


Benno.

Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)

[Benno Senoner]

On Thu, 28 Oct 1999, Paul Barton-Davis wrote:
> 
> *smile* you've got a hardware problem. i know this because i have too :)
> 
> when i had to switch (temporarily) from my Matrix G200 AGP video card
                                                              ^^^^^^^^^^^
I didn't know that "The Matrix" was developed by Matrox.
:-)

> to an old ISA-based Diamond Speedstar, the performance of my audio
> stuff has gone down the tubes. i can't do *anything* with X and hope
> to not get dropouts. this never happened with the Matrox card, and i
> am very confident that as soon as Matrox ships me a new one, the
> problem will go away.
> 
> right now, my system is essentially useless for audio work unless you
> avoid using X. totally useless. i can't even play WAV files without
> *huge* dropouts, and thats on a *dual* PII-450 !

Yes,

the idiotproof test is the following:
install 2.2.10 + lowlatency patch  ( not SMP !), 
tune the IDE diskas as described in the README
and run a testsession
if the GFX stress graph is the only bad graph,
then I'm sorry but you have to throw away your videocard if you want
to do reliable low latency stuff.
:-)

Benno.

Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)

[Jaroslav Kysela]

On Fri, 29 Oct 1999, Benno Senoner wrote:

> > > BTW: which card are you using ?
> > 
> >   For MIDI I'm using a Roland MPU-IPC-T card.  MPU-401.
> 
> Jaroslav do you know if there are similar problems on this card with too little
> MIDI TX/RX FIFO size  , and/or lack of an IRQ connected to it ?

Yes, the problem is in the MPU-401 hardware specification. This hardware
haven't the TX interrupt. Every soundcard with the standard MPU-401
emulation has this problem.

							Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org

Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)

[Jaroslav Kysela]

On Sat, 30 Oct 1999, Billy Biggs wrote:

> On Sat, 30 Oct 1999, Jaroslav Kysela wrote:
> 
> > On Fri, 29 Oct 1999, Benno Senoner wrote:
> > 
> > > >   For MIDI I'm using a Roland MPU-IPC-T card.  MPU-401.
> > > 
> > > Jaroslav do you know if there are similar problems on this card with
> > > too little MIDI TX/RX FIFO size, and/or lack of an IRQ connected to
> > > it ? 
> > 
> > Yes, the problem is in the MPU-401 hardware specification. This hardware
> > haven't the TX interrupt. Every soundcard with the standard MPU-401
> > emulation has this problem.
> 
>   What card would you recommend for responsive MIDI then?  Or, should I
> not care, and just make sure I code to be as low-latency as possible?

Chipsets with full IRQ based RX & TX:

Trident 4DWave DX or NX
Creative Ensoniq AudioPCI (ES1370,ES1371,ES1373)
Gravis UltraSound

							Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org

Re: Sync Issues (was Re: External MIDI Sync using OSS/Free)

[Billy Biggs]

On Sat, 30 Oct 1999, Jaroslav Kysela wrote:

> On Fri, 29 Oct 1999, Benno Senoner wrote:
> 
> > >   For MIDI I'm using a Roland MPU-IPC-T card.  MPU-401.
> > 
> > Jaroslav do you know if there are similar problems on this card with
> > too little MIDI TX/RX FIFO size, and/or lack of an IRQ connected to
> > it ? 
> 
> Yes, the problem is in the MPU-401 hardware specification. This hardware
> haven't the TX interrupt. Every soundcard with the standard MPU-401
> emulation has this problem.

  What card would you recommend for responsive MIDI then?  Or, should I
not care, and just make sure I code to be as low-latency as possible?

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca