Re: [linux-audio-dev] audio card for linux (and audiality ?)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] audio card for linux (and audiality ?)
From: David Olofson (audiality_AT_swipnet.se)
Date: la elo    28 1999 - 15:56:28 EDT


On Sat, 28 Aug 1999, Benjamin GOLINVAUX wrote:
> To achieve that, what I need is a stable OS (with low latency if I want to
> do processing in addition of basic recording/playing).
>
> stable : Linux
> low latency : RTLinux (audiality ?)

It seems that Linux will soon be able to provide "very firm" hard real time in
user space, with Mingo's patches. (The ones Benno Senoner is testing.) The
performance seems very reliable so far (*never* a scheduling latency peak higher
than the occasional 2.9 ms one!), so if you can do with some 4-7 ms of latency
(depending on how much CPU power you need to use), you won't need RTLinux.

WITH RTLinux, however, jitter is reduced to incredibly low values (peak 25 us
on a heavily stressed P120 according to Zentropix [www.zentropix.com], around 5
us on Celeron and P-II boxes according to users on the RTL list), so the only
obstacle when trying to get lower latency is the sound card hardware: Many
cards cannot DMA less than 32 bytes at a time and similar figures...

I'm a bit short of time ATM (due to a song I must get recorded and mixed this
weekend), but after that, I'll go back to Audiality hacking (the Driver
Programming Interface layer first of all) and do some real contributing to this
plug-in API.

I'll do some benchmarking on the RTL AudioPCI driver, and I'll also try other,
non-PCI cards, as they usually don't have the DMA burst size limitation.

Latest figures with AudioPCI:
             fragment size: 32 bytes (DMA burst limit)
               sample rate: 44100 Hz
             sample format: 16 bit stereo
         read/write buffer: 36 bytes

 resulting in->out latency: 64 bytes; around .4 ms.

I stressed the disk and X some, and as expected, this had no effect on the real
time code. Rock solid. I'll do more thorugh testing and also measure the total
analog -> analog latency of the card. (I'd like to know how much the
converters and digital filters add...)

> the problem is : on which device am I going to record and play sound ?
>
> You guys seem to be deeply involved in Linux audio... Do I understand you
> are working with game devices such as SB PCI 128 or Opti931 ?

Well, I am, as I need drivers with source, or audio cards with specs... I have
a Layla for my music, and I'd *really* like to see some specs, or at least a
binary driver.

We hope that our efforts for getting better multimedia performance out of Linux,
and uniting UNIX audio software through the new plug-in API, will make Linux a
more interesting to hardware and software developers in the near future. Some
of the Big Guys are porting to BeOS, but many don't like BeOS because of it's
proprietary nature, and the risk of it ending up like all other high quality
products: killed by FUD and crap software. Why should they not consider Linux
at the time we can provide far superior performance and a flexible plug-in API
with Open Source plug-ins and engines to look at?

> OSS commercial promises support for some cards but not a single good card is
> supported, am I wrong ? (sonorus audi/o : any clue ?)

Some old pro cards are supported by commercial OSS, but I haven't heard much
about it. I think you should be able to get something together, but there's not
many cards to chose from...

> This is why I'm hacking with BeOS at the moment (promised driver for Echo
> Layla)... but the soft-real time caps don't suit me (furthermore, although
> the OS is stable, the audio server is not that stable)...

Do you have any scheduling jitter benchmark data? We're very interested in
getting some real facts. "3 ms latency with Layla" sounds good, but I would
like to know if it's reliable, if you can load the CPU in the real time thread,
if it's input -> output, or just thread -> output etc... In short: Is it a real
figure, or are they cheating like everyone else? (Except for us; we don't need
to cheat. We just fix the problem. :-)

> I have another question that's still more stupid (Don't flame me, being
> given I'm not _at all_ a driver programmer)... Would it be theoretically AND
> practically possible to use BINARY DirectSound, Multimedia (Wave) or ASIO
> drivers under linux with some compatibility layer ?

Possibly ASIO; the others are so incredibly Windoze specific, as anything else
that's designed by M$. In any case, none of those would fit very well with
the UNIX driver architecture we use around here, so it wouldn't become too
popular...

> I've heard David saying
> that his audiality engine can use oss commercial binary drivers provided it
> uses a restricted set of commands... Could it be possible ? (with the
> windows DDK manual)

The reason why non-RTLinux drivers can still be used for hard real time I/O is
mmap(). And the card + driver really *has* to map a real DMA or direct access
buffer into the system's address space, or it will be pointless. Hardware that
requires the driver to do something to read or write every buffer is limited
to the buffer rate the driver can handle. It needs to be ported to RTLinux for
RTLinux performance. If non-Linux binary drivers could be used, the same
applies. Most consumer level cards should be able to mmap() correctly, but the
high end cards tend to use higher level protocols involving DSPs (with
downloaded firmware), which is NOT good in this case...

//David

 ·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
    ·Rock Solid David Olofson:
    ·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
    ·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
    ·Open Source ·Singer/Composer


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST