St?phane Letz wrote: >>> 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. > > Well either there is a drift (and you are supposed to detect it and > take appropriate measures , but "insert or remove sample" is certainly > what you don't want in a professional application...) or there is no > drift. I guess here again we are going to "assume" people using JACK > are aware of this kind of issue and use professional level audio cards. > >>> >>> 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 >>> > > Thinking again of what differentiate poll/select versus blocking > read/write (as it was implemented in our code): say we have a fragment > of 100 frames and we want to run/process with a buffer size of 256 > frames : > > Reasoning at input side "only" for now:
Looking at "half" the question is inadequate, because while you're blocking for read (for example), the write side can underflow. You need to be able to process either read *or* write, when they become available. > > 1) poll/select would wake up the application as soon as a first 100 > frames fragment is available at input? Then the application can read > 100 frames without blocking, then the application suspends, the second > 100 frames fragment wakes up the application... read 100 frames again, > ... until we have at least 256 frames (so 3 fragments) then the 256 > frames input buffer can be processed.... and so on > > 2) the application tries to read a full 256 frames buffer, the read > returns as soon as enough frames are available in the drivers so, here > also when 3 fragments have been "internally" received? > > So what are the fundamental difference here? For a non-duplex operation, there isn't much difference. (Although you might occasionally have more or less than 100 frames available at a time. So you have to check before you transfer the data, or use a non-blocking read, in case 1, otherwise it can degenerate into case 2. -- Garrett > > Thanks > > Stephane Letz
