@Hans et al
Quote:
I know you did, and that example code really needs an update (it's a wiki...). Clearly someone copied code from somewhere else onto the wiki.
Nevertheless, the Autodocs (i.e., the specification) state that you shouldn't rely on the sound data being there. Unfortunately, the lack of streaming datatypes meant that nobody caught the error in the example code... until now.
This was my general response to Matthew when this discussion kicked off. The quoted example that the problem stems from is a naïve example - if followed verbatim you're only playing mono samples, no? Despite the possible presence of another channel or ten. Not saying it's wrong - just it's a very simple example that discounts a number of scenarios. It's also the case that if a continuous mode dt was set on OS3.9 components, the code would fail, so to be clear, this isn't a "bug" with the A-Eon implementation.
Quote:
Now, so many people have copied that example that we're better off adding a workaround to the datatype (and preferably updating the specification too).
The general solution proposed in this instance for the A-Eon data type was be to use a simple check for and loop/call to SDTM_FETCH to read the data - streaming mode or no. But, the response received was that this meant changes to the application which was undesirable (paraphrasing).
I'm looking to see how much effort and duplication it will be "fix" the subclasses to allow for non-streaming mode and sample retrieval. Might take me a while as time is at a premium right now.