On Wed, 27 Nov 2002, James Courtier-Dutton wrote: > Paul Davis wrote: > > > > > > >>>the APIs that are used to write almost all audio software code in > >>>production these days all use a callback model. > >>> > >>> > >>Sorry for questioning this statement. Of course we all don't have any statisti > >>cal data but > >>you miss what I see as the majority of applications that use audio devices: > >> > >>1) games > >>2) media players > >>3) GUI sounds (i.e. accessibility) > >> > >> > > > >this is a fair point. i apologize. i have my head so far inside the > >"audio software for musicians" box that i tend to fail to see such > >applications :) > > > >however, the very fact that the applications developers of such > >programs really don't know much (if anything) about audio programming, > >and probably don't want to know much about it either, suggests that an > >API like ALSA which exposes the full HAL is probably a mistake. again, > >i consider PortAudio a vastly preferable solution. > > > > > > > I would like to point out that a "callback" api would work just as well > as an open/write/close api for > > 1) games > 2) media players > 3) GUI sounds (i.e. accessibility) > > I have to agree with Paul on the fact that a "callback" approach is really the ONLY >real option. > Here is my reasoning: - > 1) My perspective is from "(2) Media players" and not "Pro-Audio" > 2) Sound Hardware tends to have very small buffers. > 3) For nice sounding audio, these buffers should never run dry. I.E. No XRUNs. > 4) A open/write/close api will never ever be able to guarantee no XRUNs, as it has >no control on when it will get scheduling time to do the next write. > 5) With a "callback" approach, the kernel would be notified by the sound hardware >that it was ready for new samples, the kernel could then adjust the scheduler, so >that the "callback" function was called ASAP. > The "callback" function then only has to decide which samples to give. If the >"callback" function could receive a "delay" value from the sound hardware at each >callback, a media player would then have all the information it needed to do full >audio/video sync.
Sorry, it's not as easy as you've described. It's not possible to invoke any user code from the kernel code directly. There is a scheduler which is informed that a task has been woken up. It depends on scheduler when the task is really invoked. It's quite same as for the r/w model where the application is notified over poll that something occured. > 6) I don't need "sample sync", but I do NEED "callback" based api to provide me with >"no XRUNs". I don't think that there is some difference. If the scheduler don't give you enough time, the audio stream is somehow broken on all architectures. > Summary: - > The only way to cure XRUN problems is with a "callback" based api. > All application that currently use open/write/close apis, can just as easily use a >"callback" api. Let's go and see the implementation: The callback model is good for perfect sync between applications. It can do (and does) chaining of more sources, arbitrating (removing invalid sources) and so on. It is simply something "over" the audio HAL. If it really helps, it's a different point. The discussed difference (a few months ago) was in a count of the task context switches. With jack, you have these context switches (daemon and two applications mixed together) for one period of samples (* means a context switch): jackd -*> app1 -*> app2 -*> jackd -> soundcard With r/w model and a sample mixing server implemented in the user space, you can get this for one period of samples: mserver -> soundcard -*(ring buffer does not contain enough samples)> app1 -*(ring buffer does not contain enough samples)> app2 In real real-time setup, there will be two periods (thus app1 and app2) will be woken up all times. So, in real world the context switches are for one period of samples: mserver -*> app1 -*> app2 or mserver -*> app2 -*> app1 Note: mserver implementation uses same assumptions as jack (or any other callback model). The ring buffers are shared between app and mserver and the period of samples is a constant. The playback / capture pointers are incrementing by the period size steps. Thus there is no need to commit result directly back to the mserver. mserver will be woken up by the kernel scheduler when next poll() event occurs (on next period boundary). Ok, it's only simple example, that there are more solutions than Paul suggests. I fully agree, that the callback model is suitable for the perfect synchronization among more applications. Also, imagine that mserver is not using a soundcard as output device, but jackd. So, applications using r/w can use benefits of jackd (of course, there will be one more period of samples buffered, but who will care when the start is synchronized?). In my brain, there is also totaly different solution with the zero context switching overhead - sharing the soundcard DMA buffer among more applications. There is only one problem: snd_pcm_rewind() implementation cannot be perfect, because of wrapping added sample values (we lose information which cannot be recovered). The question is, if it's a fatal problem. Let's discuss these things. Hopefully, I'll get some time to implement at least the mserver functionality. Jaroslav ----- Jaroslav Kysela <[EMAIL PROTECTED]> Linux Kernel Sound Maintainer ALSA Project, SuSE Labs ------------------------------------------------------- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel