OpenAL Specification and Reference | ||
---|---|---|
<<< Previous | State and State Requests | Next >>> |
By default, AL uses seconds and Hertz as units for time and frequency, respectively. A float or integral value of one for a variable that specifies quantities like duration, latency, delay, or any other parameter measured as time, specifies 1 second. For frequency, the basic unit is 1/second, or Hertz. In other words, sample frequencies and frequency cut-offs or filter parameters specifying frequencies are expressed in units of Hertz.
![]() | RFC: Query and Factor? |
---|---|
Will time be an AL state that can be queried and scaled? AL usually (always) implements a real-time process with the constraint that it has to be synchronized with the time as experienced by the user. Do the units used with respect to time and frequency have a fixed meaning? |
![]() | RFC: Setting Time/Long |
---|---|
Given a frequency range from a few Hz to 50kHz or more, we need a temporal resolution of 20 microseconds or less. For simplicity that means we either resolve Milliseconds and loose precision, or we resolve microseconds. Applications might run hours or days, which is 10E5 seconds or more. If we cover 12 orders of magnitude (10E6 to 10E-6) 32bit unsigned integer will not suffice. Do we introduce a 64 signed integer for the purpose of specifying time over a duration of several days at microseconds resolution, or do we use two 32bit integers, and how do we split them? |
![]() | RFC: Duration Query |
---|---|
The application might want to cull Sources based on how many milliseconds are left for their current buffer or queue (either to stop those that will stop soon anyway, or to stop those that will take too long, depending). We need to divorce sample (memory) count from duration, because of compression and differences between internal and external sample format. Duration can be queried in microsecond resolution in case we want to account for O(10Khz) sampling frequencies properly, or milliseconds if we do not anticipate the need to go beyond typical operating system time resolution. We need query as double, float, and possibly long (as of now an undefined data type). We might need an INVALID_RANGE error on the getter, especially if large reptition counters can be set. For paused source, the remainder will be the same as for playing sources. The application can query the Source State to find out the additional information. INFINITE is not needed, no is UNKNOWN as we operate on known queues. |
<<< Previous | Home | Next >>> |
State and State Requests | Up | Space and Distance |