St?phane Letz wrote: >>> >>> 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?
Over the long term average, there really shouldn't much drift. Frankly, I'm not sure how you cope with it. Perhaps simply detect it and insert or remove samples of silence ... and log a warning... you probably don't need to do more than that, because it really shouldn't happen if the clocks are accurate. >>> >>> 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. Sure. If you're using poll(), you should do it for all OSS systems, not just Boomer. The technique isn't just correct for Boomer, but for all OSS systems. (And depending on the fragment size being a power of two is "wrong" for all "modern" OSS implementations, even though it might frequently work.) -- Garrett > > Stephane Letz
