Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)

From: Stéphane Letz <letz@email-addr-hidden>
Date: Fri Jun 17 2005 - 11:35:15 EEST

Le 17 juin 05 à 01:51, Jay Vaughan a écrit :

>> Maybe the timers used aren't precise enough for this.. I don't know.
>> Anyone?
>>
>
> coreaudio does dynamic re-sampling of its 'common feed-pool' ring-
> buffer for audio i/o, so maybe this delay compensation is factored
> in that calculation?

I think coreaudio does not do resampling in the HAL directly but at a
upper level. There is a generic AudioUnit called AudioConverter that
can do all kind of stream manipulations (interleave/deinterleave,
resampling, channels mapping....) and the applications are supposed
to put between the HAL API and their own IO proc. AudioConverters are
altivec optimized on G4 and quite fast even on G3: for example the
interleave/deinterleave code is at least 2 times faster compared to
what one would write with a standard loop.

They can also use a AudioUnit called AUHal that internally uses
AudioConverter to address the real driver. A lot of applications now
this AUHal layer that simplify the job of going from the format,
sampling rate... the application wants on what the choosen real
driver can do.

The coreaudio driver inside jackosx uses this AUHal audiounit for
example.

Stephane

>
> multiple clients with independent sample-rates/bit-formats can be
> doing their thing in OSX, a nice and good thing in my opinion
> (means you can have very small soundfiles for very small events
> while also doing the whole dvd dolby/5.1 thing at the same time) ..
> and i have not seen latency issues yet, except for maybe poorly
> written USB-audio drivers, here and there .. of course, there are
> tons of DAW's on OSX who don't necessarily use CoreAudio
> extensively yet, but there are a few OSX-native (not a port) apps
> that can demonstrate CoreAudio doing the work (intuem, etc.)
>
> i know its fast for what its doing, this re-sampling business.. at
> least on my powerbook .. altivec? i've got tons of RAM too,
> though, maybe thats got at least something to do with it .. ermm,
> maybe thats not so technical, but i can say that OSX' approach of
> the kernel doing the monkey business around a common API-bound ring-
> buffer while all apps are in sync seems to have delivered the goods ..
>
> --
>
> ;
>
> Jay Vaughan
>
>
Received on Fri Jun 17 16:15:04 2005

This archive was generated by hypermail 2.1.8 : Fri Jun 17 2005 - 16:15:05 EEST