User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
Glad you solved it. I figured it might be not of much help.
It helps me a bunch though. I'm always getting into messes like
that where I even just need to print what the buffer sizes are
resolving to. I get mixed up a bunch with simple things in C/C++
like order of operations and floating point/non-floating point
maths.
For example, to calculate the buffer frames required for a given
period I use this:
template<typename
Rep,typename Period>
static size_t calculateBufferFrames( const
std::chrono::duration<Rep,Period> &period, size_t
samplerate )
{
// Now how much period is in a second
(because the samplerate is a full second)
auto per_second =
std::chrono::duration_cast<std::chrono::duration<Rep,Period>>(
std::chrono::seconds( 1 ) );
// Now do the math
return(
period.count()*samplerate/per_second.count() );
}
I used to have ( period.count()/per_second.count() )*samplerate
which works fine if you do it with a calculator, but will produce
0 if done here. That caused me a bit of grief with the buffers
until I did some print lines.
Maybe I'm just inexperienced :D.
Michael A. Leonetti
As warm as green tea
On 9/22/19 10:34 PM, Jonathan
Brockerville wrote:
Thanks, Michael. That is some serious console
debugging code. :)
Turns out I may have fluked into solving it. I can't
explain it just yet, but it feels right. I was trying buffers
with different sample rates, byte rates, and number of
channels. One test didn't do the repeating thing. It was a
buffer size of double the byte rate. I changed all my tests to
allocate a buffer of double the byte rate and they all worked.
We'll see if that holds true with more rigorous testing
though. :P
Maybe not helpful, but if it were me I'd std::cout the
heck out of the code to see in what sequence everything
occurs. I would, do this:
Use some serious print lines as many places as you
can, especially on the EOF function, and the functions
where you're writing your audio source also with memory
locations.
Create output files with whatever the same data is
that you write to the media buffers, write to the files
(name them each differently each time EOF occurs close
the file and reopen). Afterwards open the files with
audacity or something (especially if they're raw PCM)
and hear what they sound like.
This is how I debug stuff like this. If the output files
are also weird, then that might tell you something about
what's going on.
Here's a quick and dirty (and ugly) library I wrote for
just such occasions that you can easily turn on and off.
// Intelligent debug COUT code to
stop code duplication
// Quick class for differentiating when we don't have a
string
class DebugCouts_NoStringType : public std::string {}; //
Make it a string type
#endif
/**
* Prefix name of the logger functions you want.
* For example DEBUG_COUTS( MyClassFile, true )
* will make the log functions COUT_LOG_INFO,
COUT_LOG_WARN, COUT_LOG_ERROR
* For use like
* COUT_LOG_INFO( MyClassFile ) << "This will get
thinged?";
* Or just
* COUT_LOG_INFO( MyClassFile );
* Setting the second parameter ACTIVE to "false" causes
everything to be compiled out except for the iostream code
which adds some bloat
*/
#if defined( DEBUG )
I'm trying to create a continuous memory player
(for lack of a better description). Here's what I'm
doing. Create a memory player with looping enabled.
When it gets to EOF the callback method is invoked. I
update the memory with new audio data and return true.
This basically works, however, I keep getting a little
snippet of the previous audio data. It's as if the
callback is invoked slightly after the rewind happens.
I assumed that execution would be: play memory, EOF
callback, rewind memory, play memory, etc. That
doesn't seem to be the case. What am I getting wrong
here?
I also tried disabling looping, but I couldn't
figure out how to manually rewind the memory and
transmit again. Destroying the memory player,
re-creating it, and pointing at the same but updated
buffer seems heavy handed.
