On Thursday 11 July 2002 17.19, Kai Vehmanen wrote:
[...]
> If using a large FIFO between a non-rt and rt threads, then the
> best solution is to make the FIFO nonblocking using atomic
> operations. This is an essential technique when making robust
> user-space audio apps. Real-life implementation cans be found from
> ardour (disk butler subsystem), ecasound (classes
> AUDIO_IO_BUFFERED_PROXY and AUDIO_IO_PROXY_SERVER) and EVO
> (formerly known as linuxsampler).
"sfifo" is another one, which I've been using in various environments
for some time:
http://olofson.net/mixed.html
Simple read/write style API. Linux kernel support for kernel drivers
included. (Has been used in RTLinux drivers as well as standard
kernel drivers.)
(BTW, I would be grateful if someone could verify the critical
sections to make sure that it works with more tricky compiler/CPU
combos. Max 24 bit atomic limits and stuff... Only tested with
x86/PM32, x86/Real Mode, PPC and some PDA CPUs, mostly with GCC and
old Borland compilers.)
[...]
> So like Paul said, do we need to support these soundcards...? For
> JACK-style operation both the above scenario are really, really
> bad.
--votes;
I don't think "proper" support for some rare (I hope!), broken
hardware is a good reason to make application programming harder than
it is already. A proper bus interface is a requirement for a serious
audio card, just as a good SNR, reliable digital I/O, or whatever.
[...]
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`---------------------------> http://www.linuxdj.com/maia/ -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'
