>> >> Do you mean with an input and output rate that would not stay in >> synch? What is the application supposed to do (for example in a >> input ==> some processing ==> output case) Resample? > > In general, the sample rates *should* be the same, but there could > be some clock drift. The *fragment sizes* might also not be the > same, even if the clock rates are. Resampling shouldn't be > necessary, but tying the input quantum to the output quantum > *might* be a mistake.
How can you avoid to resample in presence of clock drift? >> >> Do we at least agree on the fact that a duplex processing >> application *cannot* use more than the time slice represented by >> the buffer-size value the application processing part is using, >> *on average* ? >> >> (I agree that for a *given* cycle this may be more, if the output >> buffer has some frames in advance to compensate...) > > Yes, I think I would agree with that. OK ((-: >> >>> >>>> >>>> So to summarize, we prefill output a bit to avoid underruns, >>>> then the Read / Process/ Write is supposed to work at the right >>>> speed. And this one thread model simplify others parts: we don't >>>> need to use additonal "ring-buffers" or "queues" to move data >>>> between the thread that calls the graph "Process" and the one >>>> that would call Read/Write. >>> >>> Okay, one thread will work for you, but you need to use the poll >>> or ioctl or nonblocking approaches I've already pointed out >>> then. My sample code should help you out there. >>> >>> Actually, with your crazy processing considerations, probably >>> what we should do is look into getting you mmap(2) support, where >>> you can just run completely disconnected from the kernel code, >>> and use whatever speed and rate is most comfortable for your >>> server. Unfortunately, the mmap(2) syscall isn't supported by >>> Boomer Phase I (it will be in Phase II), and in any case it isn't >>> portable to all drivers. (4Front's code only supports it on >>> Linux, and only for some devices ... e.g. USB audio probably >>> doesn't support it because USB devices don't use memory mapped IO.) >> >> Yes I know mmap would be much better (used in JACK ALSA backend >> in Linux) > > Hopefully you'll be able to use it in a couple of months when we > have Boomer Phase II ready for test. > > And I guess II'll have to go the "poll" way untill then. I'll do that in my separated jackBoomerDriver class for now. Thanks for the discussion. Stephane Letz
