Rephrasing my ALSA question - Does the example code work ?

Rudy, I'm trying to make you think about the problem so you have the satisfaction fixing whatever may be wrong yourself. 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 or the facts are telling you, you don't stop and consider if you are down a blind alley.

You have no idea whether the correct amount of data is being played. All you have is the time it takes for the code to execute.

So why do think the sound playback time is the same as the program execution time?

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?

mm0fmf,

Actually, I do. And it doesn't. Thats something I'm rather sure of.

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.

:-) 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.

:-) I've done a number of different tests (with measuring time being one of them) all showing that the sound indeed gets cut off.

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 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

Michael,

Yes, I understood that he vaguely hinted at (but not said) that. I guess it shows that that vagueness irked me.

As described in the test at the end of the post you're responding to, it isn't.

But, if you doubt that test (or its results) than please do advice another (better?) one. I'm rather stuck here, so anything is welcome.

You know whats frustrating - besides obviously noone here owning an RPi

3B(+) board and programming C(++) on it that is ? Although it was for another, bit more complex bit of example code my first post in this thread described that above "does it really gets cut off ?" test in points 1) and 2) . I think it shows that I was aware of that "could keep playing after the program ends" possibility.

Regards Rudy Wieser

P.s. This one uses a single buffer. The "cut off" problem is the same. As mentioned by the poster.

You can always tell Rudy but you can't tell him much.

mm0fmf,

And I tell you that the sound runs short, and you refuse to believe me. You're the proverbial pot who tells the kettle off for being black. Funny that, right ? (no, not really)

I /really/ wish you would have access to an RPi 3B(+) board and with it be able to actually test that code, and realize that I was right all this time. My second wish would be to be able to see your face at that moment.

Goodbye, as we probably won't be speaking each other anymore.

Regards, Rudy Wieser