<div dir="ltr">Re: time vs samples I'm more worried about the extra complexity for the main use cases I know of than precision, but it's true that this does make the code completely device frequency neutral.<div><br>
</div><div>I do need to check out the sample mixing process more in depth to ensure the mix can align two same frequency samples when they're on a different clock, which will require sub-sample accurate timing. Currently I just offset the write output which makes things really easy, but won't work for different frequencies.</div>
<div><br></div><div>Thanks for the info on alMain, SOFTX etc., will get to work on all that!</div><div><br></div><div>Many thanks for all the feedback!</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 28 January 2014 01:19, Chris Robinson <span dir="ltr"><<a href="mailto:chris.kcat@gmail.com" target="_blank">chris.kcat@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 01/27/2014 02:16 PM, Doug Binks wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Output frequency - indeed I think this could disappear from the return as<br>
it's relatively non volatile. However I'd like to leave the option to get<br>
samples rather than time as it makes the code easier to use. Adding a get<br>
time rather than samples as per latency makes sense though for some cases.<br>
</blockquote>
<br></div>
It's possible to convert the clock time (and update time) back to sample count if needed (at microsecond resolution you should be able to convert back and forth just fine up to 500Khz, and nanosecond should handle up to 500Mhz). By having the clock in microseconds or nanoseconds, an app can also convert it directly to/from the source buffer's sample rate if it needs to, and avoid the device's rate altogether... you can largely ignore the fact that the device has a sample rate and just consider the sources individually.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Please be as mean as you can with the code, even though it's just a<br>
prototype to show this can work. Meanwhile I'll look into the proposed<br>
changes and clean up the example a bit. I'm trying to stay away from using<br>
SDL for now to reduce dependencies with the example I wrote hence the<br>
slight repeat of code.<br>
</blockquote>
<br></div>
Aside from stuff already mentioned, in-progress extensions should have their tokens and things added to the private alMain.h instead of the public alext.h. The extension string should also use SOFTX instead of SOFT while it's being worked on and is subject to changes. And since it will probably be adding new device-level queries and methods (I imagine there will be a new alGetInteger64vSOFT function to get the device clock on its own), it should be an ALC extension.<div class="HOEnZb">
<div class="h5"><br>
______________________________<u></u>_________________<br>
openal mailing list<br>
<a href="mailto:openal@openal.org" target="_blank">openal@openal.org</a><br>
<a href="http://openal.org/mailman/listinfo/openal" target="_blank">http://openal.org/mailman/<u></u>listinfo/openal</a><br>
</div></div></blockquote></div><br></div>