Re: [alsa-devel] Re: [rtl] Low-latency patches working GREAT (<2.9ms audio latency), see testresults

Re: [alsa-devel] Re: [rtl] Low-latency patches working GREAT (<2.9ms audio latency), see testresults

[Paul Barton-Davis]

Linus wrote:

>Guys, if anybody thinks we're competing with BeOS, then wake up. BeOS is a

last i heard, we weren't "competing" with anyone. we were trying to
write a really really good OS. 

BeOS is unique in that its the first vaguely stable OS to be designed
with multimedia in mind from the ground up. there are those of us who
see computing technology as either currently or very soon delivering
the power to do things with audio and video that have been hard to do
without special purpose hardware as little as two years ago. right
now, linux is not the right platform for doing this, and BeOS is, and
I don't like that.

there is persistent denial on l-k and elsewhere that an OS designed to
effectively support "traditional" computer usage (compilation, number
crunching, data serving) has any fundamental differences from one
based around, say, real-time audio generation & manipulation.

i doubt that this is true, but burying our heads in the sand won't
change the answer one way or another. i personally suspect that the
only reason BeOS has a niche *at all* is (1) because its true that there
is a difference and (2) because there are companies out there who
would like to develop for something better than Win/Mac and are scared
to do the linux^H^H^H^H^Hright thing.

it would be very nice to be able to compile linux with options that
say, in essence: "this is a mostly single-user box with little or no
network use, not much disk I/O that really benefits from a smart
filesystem, and regular use of soft-real-time tasks that want to take
over the machine if at all possible."

this is a profile that has a very different emphasis from many of the
things that kernel folks are working on supporting. to dismiss this
kind of system as a "niche" is to potentially miss a broad wave in
computing usage over the next decade or so. IMHO.

>niche OS that isn't worth competing against, and at most we can try to
>find out what it's good at and see if we can emulate some of it. But 25%

"emulate" ? i'd rather we copy it and/or do it better.

>disk IO decrease is definitely not something we want to even consider.

oh come on linus - nobody has gotten close to suggesting that its an
acceptable change! benno was merely observing the current status of
things. i strongly suspect that victor's "tunable parameter"
suggestion could solve quite a bit of the difference.

--p

Re: [alsa-devel] Re: [rtl] Low-latency patches working GREAT (<2.9ms audio latency), see testresults

[yodaiken]

On Sun, Aug 29, 1999 at 03:34:41AM -0400, Paul Barton-Davis wrote:
> BeOS is unique in that its the first vaguely stable OS to be designed
> with multimedia in mind from the ground up. there are those of us who

What does that really mean? MacOS is pretty good for multimedia
if that is all you want to do and you have simple multimedia.
Can you drive a robotic system, sampling sensors, driving a display,
operating a feedback control loop, and pulling data from a large
scale data base using Beos?  I doubt it. Beos offers low latency for
simple tasks, but DOS does that too.

> see computing technology as either currently or very soon delivering
> the power to do things with audio and video that have been hard to do
> without special purpose hardware as little as two years ago. right
> now, linux is not the right platform for doing this, and BeOS is, and

I never see any published data on BeOS benchmarks so it's hard to evaluate.
But there are some obvious problems with the OS in terms of 
(A) hard rt response (none) (B) high speed networking (not) (C) high
bandwidth disk io ...

> there is persistent denial on l-k and elsewhere that an OS designed to
> effectively support "traditional" computer usage (compilation, number
> crunching, data serving) has any fundamental differences from one
> based around, say, real-time audio generation & manipulation.


Specifics would be useful. We need a
multimedia component of lmbench.

Re: [alsa-devel] Re: [rtl] Low-latency patches working GREAT (<2.9ms audio latency), see testresults

[Paul Barton-Davis]

Victor "Not Really A Curmudgeon" Yodaiken writes:

>What does that really mean? MacOS is pretty good for multimedia
>if that is all you want to do and you have simple multimedia.
>Can you drive a robotic system, sampling sensors, driving a display,
>operating a feedback control loop, and pulling data from a large
>scale data base using Beos?  I doubt it. Beos offers low latency for
>simple tasks, but DOS does that too.

absolutely. and DOS is a pretty reasonable platform for developing the
kind of audio applications i am interested in these days, except that
it lacks 90% of the desired environment as the price of letting me
take over the machine when i need to. but yeah, DOS is great: its just
an extended interrupt handling mechanism, and as such, rarely, if
ever, gets in the way when its not supposed to.

>I never see any published data on BeOS benchmarks so it's hard to evaluate.
>But there are some obvious problems with the OS in terms of 
>(A) hard rt response (none) (B) high speed networking (not) (C) high
>bandwidth disk io ...

(A) mostly irrelevant for real-time audio generation/processing if soft rt
    response is good
(B) irrelevant for RT-AG/P
(C) not needed (low bandwith is adequate) for RT-AG/P

>> there is persistent denial on l-k and elsewhere that an OS designed to
>> effectively support "traditional" computer usage (compilation, number
>> crunching, data serving) has any fundamental differences from one
>> based around, say, real-time audio generation & manipulation.

>Specifics would be useful. We need a
>multimedia component of lmbench.

i don't know what kind of specifics you want, but i'd like to be able
to write a program that, despite running on a multitasking, multiuser
OS like Linux, can plan on basically having access to the same
hardware performance characteristics as if it were running without an
OS. 

That is, if I have an loop that wants to do this:

     generate 32 samples
     read 32 samples from an A/D converter
     do some math with the 32 read samples
     mix the generated and read samples together
     send them to a D/A converter
     sleep for 0.5ms

then i'd like it to work under Linux without worrying that:

     (1) the 32 samples will take more than 32*1/sampling-rate secs to
         generate (assuming that this is theoretically possible given
         the nature of the computation involved and the CPU speed).
     (2) that reading 32 samples from the A/D converter will take
         longer than the actual transfer time.
     (3) that writing 32 samples to the D/A converter will take
         longer than the actual transfer time
     (4) that i might sleep for too long

The above numbers are reasonable, but not necessarily the ones to
use. 

Why do I want to use Linux (or any OS) ? Because no application that
does this runs all the time; because developing this application has
taken me 6-7 man-months already and that time involves a continual
cycling between development and running of the current result; because
i don't want to have write my own window system, file system, etc. etc.

--p

Re: [alsa-devel] Re: [rtl] Low-latency patches working GREAT (<2.9ms audio latency), see testresults

[yodaiken]

On Sun, Aug 29, 1999 at 10:24:10PM -0400, Paul Barton-Davis wrote:
> Victor "Not Really A Curmudgeon" Yodaiken writes:

What's this "not really"? 

> absolutely. and DOS is a pretty reasonable platform for developing the
> kind of audio applications i am interested in these days, except that
> it lacks 90% of the desired environment as the price of letting me
> take over the machine when i need to. but yeah, DOS is great: its just
> an extended interrupt handling mechanism, and as such, rarely, if
> ever, gets in the way when its not supposed to.

Ok. So why don't you like RTLinux again?

> >I never see any published data on BeOS benchmarks so it's hard to evaluate.
> >But there are some obvious problems with the OS in terms of 
> >(A) hard rt response (none) (B) high speed networking (not) (C) high
> >bandwidth disk io ...
> 
> (A) mostly irrelevant for real-time audio generation/processing if soft rt
>     response is good

So you  don't want to control tape drives, sample mics, and do other
audio that requires precise timing?

> (B) irrelevant for RT-AG/P
No networked audio systems? Plan ahead.


> (C) not needed (low bandwith is adequate) for RT-AG/P

Streaming video. Or capture of high speed data acquisition.

>      generate 32 samples
>      read 32 samples from an A/D converter
>      do some math with the 32 read samples
>      mix the generated and read samples together
>      send them to a D/A converter
>      sleep for 0.5ms
> 
> then i'd like it to work under Linux without worrying that:

Easy as pie in RTL.

> Why do I want to use Linux (or any OS) ? Because no application that
> does this runs all the time; because developing this application has
> taken me 6-7 man-months already and that time involves a continual
> cycling between development and running of the current result; because
> i don't want to have write my own window system, file system, etc. etc.

Exactly. But you also want to rule out the working solution and want to 
believe that BEOS will be a working solution. In my humble opinion, BeOS
will fail to deliver in the long term precisely because its kernel 
design is more suited to 1980s Mac applications than to 2000+ mutlimedia
which will need to connect multimedia to big fast databases, complex
networks, and sophisticated i/o systems.

> 
> --p

Re: [alsa-devel] Re: [rtl] Low-latency patches working GREAT (<2.9ms audio latency), see testresults

[Paul Barton-Davis]

>Ok. So why don't you like RTLinux again?

Because its not Linux, and I don't want to write code for people that
comes with the proviso: you must run RTLinux, not Linux.

I freely admit that its not a very good reason, and if David Olofson's
work on a driver interface for RTLinux works out, I will most likely
change my mind, since it will make all kinds of things possible.

>So you  don't want to control tape drives, sample mics, and do other
>audio that requires precise timing?

they don't require the kind of timing that depends on the OS. the
timing comes from the DAC clock (or in some good cases, from an
external word clock source), and the point is to be able to sync
to that reliably, without the OS interfering. I don't want the OS
trying to do microsecond timing control of another piece of hardware.
its a nightmare. its bad enough that the DAC clock itself suffers from
jitter - introducing the OS as another source of this would be nasty.

when you control a tape drive you tell it where to go to, and it goes
there. when you control a sample mic, you typically collect more
information than you need, and edit it non-real-time. when you control
other hardware, you typically issue it with commands and/or a clock source.

>> (B) irrelevant for RT-AG/P
>No networked audio systems? Plan ahead.

Nope. For the kinds of applications that interest me, the latency for
any network will be unacceptable for a long, long time. Not the
bandwidth, just the latency. Can you show me any network hardware that
has 0.02ms (1 sample at 48KHz sampling) latency for "first packet in a
while" ?

>> (C) not needed (low bandwith is adequate) for RT-AG/P
>
>Streaming video. Or capture of high speed data acquisition.

I know. Thats why I said "for RT-AG/P"

>> Why do I want to use Linux (or any OS) ? Because no application that
>> does this runs all the time; because developing this application has
>> taken me 6-7 man-months already and that time involves a continual
>> cycling between development and running of the current result; because
>> i don't want to have write my own window system, file system, etc. etc.
>
>Exactly. But you also want to rule out the working solution and want to 

I don't want to rule out RTLinux. I just don't want a solution
(RTLinux or BeOS) that isn't the fastest growing, best supported and
always improving OS available.

>believe that BEOS will be a working solution. In my humble opinion, BeOS

I could care less about BeOS, which I don't really want to use. All I
care about are the performance characteristics it is aiming for.

>design is more suited to 1980s Mac applications than to 2000+ mutlimedia
>which will need to connect multimedia to big fast databases, complex
>networks, and sophisticated i/o systems.

Yes, and those kinds of multimedia applications will be (very?)
well-served by Linux.

However, real-time audio generation (*not* playback, generation) and
processing isn't going down that pathway, not until we get another
order of magnitude speed up from basic I/O subsystems and probably
CPU's as well, not to mention huge improvements in network
latency. The idea of pulling samples from an Oracle database because
someone just sent MIDI NoteOn messages to us, and then sending it over
the a network to another machine: no, I don't think so.

--p