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

[Stéphane Letz]

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
>
>