...the second quote is not talking about semaphores. It is the description of a busy loop. You can only make a connection with a timer given that you put the precondition that the data served is controlled by a crystal clock.

I don't know if you both realize that with your points, the "event based" and the "push based" API become both different timer implementations, so blurring any difference by means of "abstract concepts".

Probably by "semaphores" you actually mean "timers"?

Anyway, a busy loop is a way to implement a timer using a crystal clock.

The core idea here is that a push based system uses a timer to push things at regular intervals, while an event system does not.  The only way you can build a timer using the event system as your primitive is if the events are themselves created by the output of a timer.  This is however a circular argument, a timer can be used to construct a timer because it is a timer. 

Quote from: saratoga on 2016-02-27 18:56:46

Probably by "semaphores" you actually mean "timers"?

No. I am arguing all the time that my conception of timer does not include the concept of semaphore.

Quote

Anyway, a busy loop is a way to implement a timer using a crystal clock.

A busy loop on an MS-DOS program waiting for the user to press a key uses a crystal clock?

Or did you mean that waiting for a crystal clock on a soundcard to reach a value is waiting for a clock to reach a value? Duh!

Now i am sort of puzzled. You've described it in the exact opposite sense that I understand it:
The disadvantage of using push based method is that you either consume CPU on a busy loop asking if a value has been reached, or you put the thread to sleep for an amount of time to prevent consuming CPU and consequently there might be an undefined (and possibly variable) delay between the clock reaching the expected value, and your code reacting to that action.
And the advantage of the event based method is that the event is produced (supposedly by the soundcard driver itself) at the exact moment that the buffer is ready to be feed, so you don't consume CPU and are waken up as soon as possible.

The problem seems to go, again, around the WaitForSingleObject/WaitForMultipleObjects.

Edit: I think what you both try to tell me is that push based is timer based because the soundcard clock works at a fixed interval,

Busy loop and producer/consumer are not concepts related to a timer.

Anyway, a busy loop is a way to implement a timer using a crystal clock.

The core idea here is that a push based system uses a timer to push things at regular intervals, while an event system does not.  There is no way you can push things are regular intervals while ensuring that you do not get buffer underflows without measuring the passage of time.  The act of measuring the passage of time on a computer requires the concept of a timer.  This is all anyone is telling you. 

A push based system could do a busy wait (there are several options here, from a loop that will burn CPU over giving up the current thread's timeslice to sleeping - none of which use a timer).

You can push at regular intervals and if you do it right you can avoid buffer underflows, except in situations where the event based system would also fail on a typical desktop OS, because they are not realtime and make no guarantees...

No.

Busy loops are a common way to implement timers in audio applications.  We use more than a few in rockbox drivers for instance, often when the interval is too small to be practical to use with an interrupt on a given hardware platform.

Yes, but doing so requires you to measure the passage of time such that your intervals remain regular.  Devices for measuring the passage of time are timers.

Quote from: saratoga on 2016-02-29 21:54:18

No.

Yes, unless you actually measure the time there is no relation to time in a modern OS or on a modern computer because there are countless variables involved (scheduling, different CPUs, dynamic CPU clock rate, ...)

Quote from: saratoga on 2016-02-29 21:54:18

Busy loops are a common way to implement timers in audio applications.  We use more than a few in rockbox drivers for instance, often when the interval is too small to be practical to use with an interrupt on a given hardware platform.

You're talking embedded/microcontroller here, where you can rely on things like the hardware that you can't on a modern PC that uses WASAPI.

Quote from: saratoga on 2016-02-29 21:54:18

Yes, but doing so requires you to measure the passage of time such that your intervals remain regular.  Devices for measuring the passage of time are timers.

Not necessarily. You don't have to wait until the buffer is half empty, or fill it at such an interval. You could for example just try to fill it in a tight loop.

Nonsense.  You still have to design your loop to poll based on the worst case clock speed.  If you actually tried to design a push system where you literally had no idea what the clock speeds were you'd likely fail and get dropouts.

Actually, in rockbox we also (usually) have variable clocks just like on Windows.  We just design the busy loops appropriately.  I don't see how this relates to your argument though.  You're still counting time, its just slightly more complex. 

while (!quit)  { TryToFillAudioBuffer(); }

Yes necessarily.  Tight loop is a timer in that it measures the passage of time and produces an action at predictable intervals (specifically, the action must happen at least as often as the minimum buffer period). 

I don't see why people keep getting mixed up in the details here.  "Push" is an algorithm, not an implementation.  It defines a series of actions, not any specific way of doing them.  No matter how you implement it, its still the same algorithm, and it still depends critically on being able to measure time.  Think up any crazy implementation you want.  Does it work for push?  Then it incorporates a timer. 

No, what I wrote is not "nonsense" and such a reply is just as weak as your previous "no".
Clock speed is actually pretty irrelevant to what I tried to explain to you. It doesn't matter if a simple polling loop does 1k or 1 trillion cycles until the buffer has emptied far enough.

If the system is too slow to even finish a single cycle then it would also fail with WASAPI event style, so yeah... but I've told you that before.

Quote from: saratoga on 2016-03-01 18:04:58

Actually, in rockbox we also (usually) have variable clocks just like on Windows.  We just design the busy loops appropriately.  I don't see how this relates to your argument though.  You're still counting time, its just slightly more complex. 

No, as I said it's not counting time.

Code: [Select]

while (!quit)  { TryToFillAudioBuffer(); }

Where does this loop count anything let alone time?

Quote from: saratoga on 2016-03-01 18:04:58

Yes necessarily.  Tight loop is a timer in that it measures the passage of time and produces an action at predictable intervals (specifically, the action must happen at least as often as the minimum buffer period). 

No it's not necessary.

Quote from: saratoga on 2016-03-01 18:04:58

I don't see why people keep getting mixed up in the details here.  "Push" is an algorithm, not an implementation.  It defines a series of actions, not any specific way of doing them.  No matter how you implement it, its still the same algorithm, and it still depends critically on being able to measure time.  Think up any crazy implementation you want.  Does it work for push?  Then it incorporates a timer. 

No, you don't need to measure any time. The only requirement for a tight loop would be the users' system: for example it needs to be fast enough to read some chunk of a file and decode it and fill the audio buffer with it before there is an underrun.

while(!exit) {
 int i= haskeypress();
  if (i) {
    char c = getc();
    doAction(c);
  }
  printScreen();
}

All I can understand from your comments is that, since I had to take into consideration the max amount of time that i can take to do "doAction()", somehow I have a timer.

If i am still wrong, please show us very explicitely which timer are we using in this loop.

while (true)
{
for (int128_t i=0; i< randi(); i++)
{

}
push_audio_data();
}

This is wrong.  If your loop cannot be guaranteed to poll on an interval less than the buffer refill time, it will not work.  Therefore time absolutely does matter. 

So what you are saying is that your implementation must consider time... and is therefore a keeping time...like a timer.

That loop is an oscillator that counts time.  Literally.  You are configuring a circuit in your PC to oscillate and so produce events on an interval with an upper bound (the duration of the audio buffer).  This is exactly what the hardware timers in your PC do BTW.

Yes it is.  If you loop cannot meet those timing requirements, it will not work.

You cannot simultaneously say that you do not need to measure time while also saying that you must meet some upper bound on timing.  It is one or the other.

Either time is bounded or it is not.  If it is bounded, then you have implemented a timer.  If it is truly unbounded, then you have not.

If you want to make a push implementation that truly did not have a timer, you could do:
[...]

while(!exit) {
  int samplesRemaining = wasapi.getRemainingSamples();
  if ( samplesRemaining <= 0 ) {
   prepareNextBlockOn(wasapi.freeBlock);
  }
  else if (samplesRemaining > 32) {
    int millis = calcMillisFromRemaining(samplesRemaining/2);
   sleep(millis);
  }
}