>> I was not aware of the method which ALSA employed to generate the callback -
>> I just expected it to _work_ like it does in Win9x (optimistic, it would
>> appear). Okay, ALSA async is dodgy... I won't use that mode, then. But at
>> least Jaroslav has fixed it so it doesn't crash on shutdown now!
>
>Don't interpret Paul words as "the prophet saying", despite its
>experience sometime he's tempted to narrow the global range of workable
>solutions to the ones he choose.
let me tell why i do this:
what i am seeing the use of Hardware Abstraction Layer like ALSA or
OSS doing to audio development on Linux is making me very unhappy.
look over at MacOS X, where *every* audio program will be capable of
(1) sharing audio interfaces in sample sync with other audio programs
and (2) exchanging audio data in sample sync with other audio
programs.
by contrast, we see more and more people coming to ALSA, and writing
applications based around a HAL-based API that can't support that. we
end up with the stupid situation that exists on MacOS <X and Windows
(all versions, i think) where we have all these neat tools (well,
hopefully), none of which work together in the most basic sense: both
(or all) being able to send a stream of synchronized samples to an
audio interface and/or each other.
Everybody developing for these proprietary OSes understands this to be
a problem, hence the emergence of Rewire and at least 2 look-alike
APIs. The problem is, since neither Rewire nor its competitors is
built into the OS, and since the vendors are in competition with each
other, there is little hope of them becoming standards in the way that
CoreAudio will dominate MacOS X.
so i focus on designs and architectures and code that can offer us
what any contemporary operating system *should* be offering audio
application writers and users. and these days, i am trying to
discourage people from working at the HAL-level, though its hard
because i don't have enough time to simultaneously work on JACK and
ardour, and with JACK unfinished, its a rather superficial kind of
evangelism.
>This has proved wrong in past (also wrt Jack, just to make an example)
I presume this is reference to context switch costs. Yes, I was
totally wrong in the sense that its possible that use out-of-process
clients, as I've freely admitted on LAD and elsewhere. I wasn't wrong
in that the cost is still substantial compared to the in-process case,
and will limit what can be done with networks of interacting audio
"applications" if they are all out-of-process clients of a server.
>and I think he's wrong again now about async notification.
What are you claiming I'm wrong about? I've made 2 specific claims:
1) if you want safe code, you can only async-safe functions in a
signal handler. Since alsa-lib uses non-async-safe functions
all over the place, you cannot safely call alsa-lib from a
signal handler. This is not my interpretation, its POSIX. And
I didn't say that you can't do it, I said that you can't
*safely* do it. By "safely", I am merely using it in the same
sense that POSIX does - the results are undefined if you try
it.
if we had documentation that details which alsa-lib calls are
guaranteed to be async-safe, and which will remain so in
perpetuity, then people could use just those calls. however,
since ioctl(2) is not on the list, i think that alsa-lib
has some problems in this area.
2) if you can't handle the alsa side of things from the signal
handler, then you have to handle it within the main flow of
execution of some thread in your program. if its your main
thread, that implies a polling operation (not poll(2))
throughout the main thread. this is subject to all the design
problems we see in the kernel with respect to scheduling
latency. alternatively, some other thread can handle this,
woken perhaps by a write(2) call from the SIGIO handler.
but wait - that means the program is still using pthreads!
so what's the advantage here? or maybe its forked a child,
and wakes up the child? ok, so for some people thats simpler
than using pthreads, but actually harder to code, since
the child is not in the same VM space as the process
that has the ALSA device open ...
>Note I'm not saying he's "globally" wrong, i.e. I'm saying (contrarily
>to Paul) that async notification is an effective method for a range of
>applications.
perhaps you can explain, given point (1)+(2) above, how it can be used
effectively by any application without using pthreads or forking a child?
and by effective, i am including the requirement that the program not
die from time to time with random segfaults or bus errors, and that it
doesn't suffer from dropouts, assuming that the kernel is doing the
right thing for us.
--p
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
