How does not restarting the system in months affect things?

[cdigit]

Timing issues that I spent all day trying to figure out resolved themselves when I restarted my system.

Background:
I discovered miniaudio around January 2022 as a C and audio novice (still). I was immensely encouraged by the library and community and was able to get some great things done that seemed previously unimaginable. I'm working on a huge and complex project with multiple programming paradigms throughout the entire stack, which makes context switching painful. I left the C/miniaudio world in late January to dive in another realm of the app, I've just come back to miniaudio and started looking over my notes, testing code and trying to reacquaint myself with C and the nuances of miniaudio.

Problem:
Timing issues related to iterating through a lists for structs that reference ma_sounds and their meta info like start_time, initializing sounds, reading frames from the engine into a ma_audio_buffer_ref, writing the buffer to a wav file via an encoder. I knew this worked flawlessly when I developed it in January because I made a happy post here about it, but today the sounds were not starting at the right time. I couldn't find anything wrong or changed. I restarted Xcode a couple of times to no avail. After hours of frustration, I restarted my system in a last ditch effort to try and fix the problem. It worked. I probably haven't restarted my system in months.

Question:
Why? What could've made it work? I'm using a Mac and Xcode. Is there some general piece of knowledge that I'm missing. Not looking to get into the weeds of code, but just from a high level, why would a system restart fix things when restarting Xcode did not? Could it be because of faulty memory management on my part? Is it a C thing, a miniaudio thing or a Mac system/hardware thing? Just wondering...

[mackron]

Can't help you much with this one. No idea what's going on there, but considering you were encountering the issue even after restarts of the program it seems highly doubtful that it's a miniaudio issue. Sounds like something is up on the system level, but I've no idea what that could be.

What do you mean by "sounds were not starting at the right time"? Do you mean there was an excessive amount of latency when playing sounds?

[cdigit]

I'll throw in some code to help with explanation.
I have a list of structs like the below. When a sound is created (recorded), the engine's global time is grabbed and I use that as the start time for the sound and stored in the struct. When I want to playback, I reset all the seek times, reset the engine time, loop through the list of structs and start the sounds. This works perfectly when playing back even when writing to disk was having problems with timing. The Timing problem was that the sounds in the list were starting later than they should have. As if there was a mismatch between the engine time and the time that was saved for the sounds when they were made.

struct SoundBox{
   int id;
   ma_sound * sound;
   ma_int64 startTime; // global time to start
   ma_int64 stopTime; // global time to stop
   ma_int64 seekTime; // internal position to play sound
   ma_int64 length; // length in terms start(record) and stoptime(recordEnd) of initial underlying data
 
};

This function will write a wav file of n sounds and a backing track. Each sound will playback as it was recorded.

void writeWav(){
    isWriting = true;
    

    // reseting the sounds to their proper seek positions
    for(int x=1; x <= counter; x++){
        ma_sound_stop(list[x].sound);
        ma_sound_seek_to_pcm_frame(list[x].sound, list[x].seekTime);
    }
    // stop backing track
    ma_sound_stop(&g_sound_1);
   
    // reset engine time
    ma_engine_set_time(&g_engine, 0);
   // rewind backing track
    ma_sound_seek_to_pcm_frame(&g_sound_1, 0);
   // start backing track
    ma_sound_start(&g_sound_1);
   // start sounds
    for(int x=1; x <= counter; x++){
       ma_sound_start(list[x].sound);

    }
    
   
    ma_uint32 framesChunk = 8;// 512; // why does frameschunk aka frameCount need to be small here (for tight timing) and not small on the device callback?
    ma_uint32 endFrame = framesChunk;
    
    ma_audio_buffer_ref * pBufferRef3;
    pBufferRef3 = (ma_audio_buffer_ref *)malloc(sizeof(*pBufferRef3));
    ma_uint64 pFramesRead;
    
    
     
    while(endFrame < recordingStoppedTime){     //endFrame < 10240000
        

          // populate the buffer with underlying node_graph data via engine
          result = ma_engine_read_pcm_frames(&g_engine, pBufferRef3, framesChunk, &pFramesRead);
        if (result != MA_SUCCESS) {
            printf("failed to read from data source"); // Failed to read data from the data source.
        }
          // encode and write the buffer, which should have data to disk
          ma_encoder_write_pcm_frames(&encoder2, pBufferRef3, framesChunk, NULL);
 
          // increment the end frame index by framesChunk
          endFrame += framesChunk;
        
    }
    ma_encoder_uninit(&encoder2);
    free(pBufferRef3);
    // kill the engine so that if the user stays here with out doing anything, it doesn't crash from not receiving a message
    ma_engine_stop(&g_engine);
    // this will allow the engine to read frames in callback
    isWriting = false;
    // stop all sounds
    printf("wrote to disk.");
}

When my system stays on for a long time, the timing of the sounds in the output wav are not as they were recorded. I'm wondering if there are issues that come up sometimes with audio and people need to restart their systems. Of course I could be doing something wrong, which is probably the case, but I basically wanted to know if audio programmers experience issues similar to this.

[mackron]

OK, the code you posted is using ma_engine_read_pcm_frames() directly which should only be used when you're not using an underlying playback device. Can you show me how you're initializing your g_engine object, including the config part?

[cdigit]

sure thing

   
 // configure device
 ma_device_config deviceConfig;
   
 deviceConfig = ma_device_config_init(ma_device_type_duplex);
 deviceConfig.periodSizeInFrames= 4; // 192;  256; //512;//256;
 deviceConfig.capture.pDeviceID  = NULL;
 deviceConfig.capture.format     = DEVICE_FORMAT;
 deviceConfig.capture.channels   = DEVICE_CHANNELS;
 deviceConfig.capture.shareMode  = ma_share_mode_shared;
 deviceConfig.playback.pDeviceID = NULL;
 deviceConfig.playback.format    = DEVICE_FORMAT;
 deviceConfig.playback.channels  = DEVICE_CHANNELS;
 deviceConfig.dataCallback       = data_callback;
 deviceConfig.pUserData          = &encoder;
    
 
// init device
  if (ma_device_init(NULL, &deviceConfig, &device) != MA_SUCCESS) {
      printf(" Failed to initialize the device.");
      return -1;  // Failed to initialize the device.
  }
   
    
    // setup encoder
     ma_encoder_config encoderConfig;
    char * outputFile = "/Users/admin/Documents/output2.wav";
    encoderConfig = ma_encoder_config_init(ma_encoding_format_wav, ma_format_f32, 2, device.sampleRate);

    if (ma_encoder_init_file(outputFile, &encoderConfig, &encoder) != MA_SUCCESS) {
        printf("Failed to initialize output file.\n");
        return -1;
    }
 
    // setup encoder for writing
    char * outputFileAll = "/Users/admin/Documents/outall.wav";
    ma_encoder_config encoderConfig2 = ma_encoder_config_init(ma_encoding_format_wav, ma_format_f32, 2, device.sampleRate);
    if (ma_encoder_init_file(outputFileAll, &encoderConfig2, &encoder2) != MA_SUCCESS) {
        printf("Failed to initialize output file.\n");
 
    }
  
    
// configure engine
    ma_engine_config engineConfig;
    engineConfig = ma_engine_config_init();
    engineConfig.pDevice = &device;
    engineConfig.noAutoStart = MA_TRUE;
    
    

    /* The engine needs to be initialized first. */
    result = ma_engine_init(&engineConfig, &g_engine);
    if (result != MA_SUCCESS) {
        printf("Failed to initialize audio engine.");
        return -1;
    }

    
        ma_uint32 channels;
        ma_uint32 sampleRate;
        channels   = ma_engine_get_channels(&g_engine);
        sampleRate = ma_engine_get_sample_rate(&g_engine);

    

    
    // start engine:
    result = ma_engine_start(&g_engine);
    if (result != MA_SUCCESS) {
        printf("WARNING: Failed to start engine.\n");
    }

[mackron]

That looks OK on surface. Where is writeWav() getting called from? The data callback? Can you post your data callback code?

[cdigit]

Not in the data callback, but It's being called via user input via keyboard: 'w'. The Data callback is below:

void data_callback(ma_device* pDevice, void* pOutput, const void* pInput, ma_uint32 frameCount)
{
MA_ASSERT(pDevice->capture.format == pDevice->playback.format);
MA_ASSERT(pDevice->capture.channels == pDevice->playback.channels);


    //get data into encoder
    ma_encoder* pEncoder = (ma_encoder*)pDevice->pUserData;
    MA_ASSERT(pEncoder != NULL);
    
    
    ma_audio_buffer_ref_set_data(&g_exciteData, pInput, frameCount);
    if(isDoing){
        ma_audio_buffer_ref_set_data(&soundBuffer, pInput, frameCount);
    }

    if(!isWriting){
        ma_engine_read_pcm_frames(&g_engine, pOutput, frameCount,NULL);
    }

    
    if(isRecording){
        ma_encoder_write_pcm_frames(pEncoder, pInput, frameCount, NULL);
    }


}

[mackron]

Just re-reading your writeWav() function now, you've got a few errors in that. I suspect you've got an error in there somewhere, but don't know for sure. Your use of ma_audio_buffer_ref is flatout wrong. Get rid of that completely. I can see you're passing it into ma_engine_read_pcm_frames(). Rework it so that you read into an array of floats. The simplest way is to simply calculate the total number of frames you'll need to read, allocate a large enough buffer on the heap, read into that buffer with ma_engine_read_pcm_frames(), then write that out with ma_encoder_write_pcm_frames(). The number of floats to allocate is equal to the number of frames multiplied by the engine's channel count (ma_engine_get_channels()). If you have a situation where the number of frames is too large to allocate in memory you might need to implement a looping solution that breaks it down a bit.

As for the timing issue, I don't have a satisfying answer for you on this one. I haven't had other reports about timing being affecting due to the system not being restarted after ages, and to be honest I find it highly unlikely to be an error in miniaudio. I was going to suggest that you ensure you don't call ma_engine_read_pcm_frames() from the data callback and your writeWav() function simultaneously, but it looks like you've got that guarded so it's probably not that.

Also, your periodSizeInFrames of 4 is way too small. I don't think it'll be causing this issue, but that will be causing a lot of unnecessary processing overhead.

[cdigit]

Ok. I will study what you wrote and reexamine what I have going on here.