R.Wieser  wrote:
> mm0fmf,
>
>> You have no idea whether the correct amount of data is being played.
>
> Actually, I do.  And it doesn't.  Thats something I'm rather sure of.
>
>> All you have is the time it takes for the code to execute.
>
> Which is shorter that the calculated one.  Are you denying that ?   If so,
> on what grounds ?
>
> Also, either in this thread or the previous one about the same subject I've
> mentioned that I can actually make the sound come out as long as the
> calculation shows it should.   So yes, I'm "pretty sure" (understatement)
> that what that linked-to code emits in regard to sound is shorter than what
> it should be.
>
>> I know, having seen how you get an idea (Python for example), right or
>> wrong, then run with it despite what other people tell you
>
> :-)   How many of those people have actually tried to run the code ?   Apart
> from Jim, NONE.  And alas, he did that on a PC, not an RPi.   Different OS,
> different hardware.  Not comparable.
>
>> or the facts are telling you, you don't stop and consider if you are down
>> a blind alley.
>
> :-)  I've done a number of different tests (with measuring time being one of
> them) all showing that the sound indeed gets cut off.
>
>> So why do think the sound playback time is the same as the program
>> execution time?
>
> Why do you think I think that ?  Is that the /only/ possibility that would
> make my "too short" claim valid ?    Are you sure ?
>
> And no, a few different tests I did (one of which I posted) have already
> shown that the /other/ possibility doesn't exist.    Yes, I have also
> thought of that.
>
>> What could possibly be happening outside your code such that the program
>> executes in less time than you expect but leads to the correct amount of
>> data being played?
>
> What makes you think that "the correct ammount of data" is actually being
> played ?    What do you base that on ?   Whisfull thinking perhaps ?   :-(
>
> Also, although I've not mentioned it, I did a test (on two different
> examples) where I kept all buffers Zero, but for (the last part of) the last
> one (upto half a seconds worth of it).  Guess what I didn't hear.
>
>
> I *really* wish you would be able to run that example code for yourself and
> duplicate my tests and see for yourself.  Now you are just contradicting me
> for the heck of it.    Sigh ...
>
> Regards,
> Rudy Wieser
>
>
>

I think he’s suggesting that the code terminated prior to the end of the
playback, because the sound is being played by interrupt-driven code
outside your program.

That’s why the actual playback duration could be longer than the execution
time of your code.

--
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

--- SoupGate-Win32 v1.05