>> >Our only requirement is to know how many samples are currently >> in the audio >> >buffer. >> >So, if we send another sample to the buffer, we can calculate exactly how >> >long it will wait in the buffer before being played. >> > >> >For what type of real-time applications would this approach not work? >> >> as just one example, those that want to work in tandem with other audio >> (+ video) applications. see my message (probably next one up) in >> response to abramo for more on this. >> >> --p >I read that email. It made no sense to me and did not answer my question: >For what type of real-time applications would this approach not work?
suppose your application is not talking to an audio interface at all? suppose i'm routing your application's audio signal to an HDR? or a filter stack? the question "how many samples are currently in the audio buffer" is rooted in the idea that the output is some kind of device with a buffer. since i think that *any* audio application should be able to talk to any other audio application, that means that i don't think any audio application should be trying to ask this question. that said, i entirely understand. ardour has a function call "audible_frame()", which returns the frame number that we believe is currently emerging from your monitors (it takes into account external latency as well as what happens in your computer). it would be very hard to make the GUI display correct without this function, and i am thinking much about how to support this concept in a callback "statefree" system like JACK. --p _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
