From: Paul Barton-Davis <pbd@Op.Net>
To: linux-sound@vger.kernel.org
Subject: Re: [alsa-devel] Re: [rtl] Low-latency patches working GREAT (<2.9ms audio latency), see testresults
Date: Mon, 30 Aug 1999 02:24:10 +0000 [thread overview]
Message-ID: <marc-linux-sound-93597903902462@msgid-missing> (raw)
In-Reply-To: <marc-linux-sound-93591224029231@msgid-missing>
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
next prev parent reply other threads:[~1999-08-30 2:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-08-29 7:34 [alsa-devel] Re: [rtl] Low-latency patches working GREAT (<2.9ms audio latency), see testresults Paul Barton-Davis
1999-08-29 16:01 ` yodaiken
1999-08-30 2:24 ` Paul Barton-Davis [this message]
1999-08-30 5:17 ` yodaiken
1999-08-30 18:34 ` Paul Barton-Davis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-sound-93597903902462@msgid-missing \
--to=pbd@op.net \
--cc=linux-sound@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.