Reading through and loading new tables simultaneously - stutter/pop

[jacksongoode]

Hello,

I've noticed that there appears to be a pop/dropout (and strange sync issues) while I've been attempting to load and play sound files over unique 4 tables, where any of them might be playing at the same time. I was wondering if this is an issue with how I change and play the new tables or if its an issue with python locking the C process while changing.

I am using a pattern to trigger this call to load a new sample into one of the tables and then read it. The dropout appears to happen after the call and affects all sounds that are in the process of being played.

In my code there are unique asdrs, tables, and osc objects for each sound I play (and they are globals in this function). Also, I should note that this function appears before "main" (I saw that in some of your examples you have the functions called by a pattern after starting the server or other elements).

I should also add that I prototyped this with SfPlayer and it played and transitioned flawlessly. I was thinking that reading into memory might offer some performance benefit (as well as the ability to manipulate tables).

def rotate_pat:
    #  i is a number between 1-4
    adsrs[i].stop() # for safety, but already stopped by the asdr
    tables[i].setSound('new_sound.wav')
    oscs[i].setTable(tables[i])

    freq = tables[i].getRate()
    dur = tables[i].getDur()
    oscs[i].setFreq(freq)

    adsrs[i].setDur(dur)
    adsrs[i].play()

    pat.set('time', dur) # sets the next time to change

And thank you for making one of the most comprehensive Python audio packages to date - it has so far replaced Pd/Max for my project.

[belangeo]

Loading sounds in memory while the audio playback is started is not a good practice. Reading on disk and loading memory takes time and can block the audio computation for too long... Either you pre-load all your sounds before starting the audio server (if you have enough memory for all sounds) or you use SfPlayer (which reads directly on disk (cost a little more on the CPU)) for very long sounds...

As a side note, you don't necessarily need as much readers than your number of sound tables, Osc.setTable() call cost nothing!

[jacksongoode]

Thanks for your response.

I did switch to SfPlayer which has been working. The main hurdle is that these audio files are being dynamically generated by a subprocess so they have to be loaded and then discarded. I'm guessing the best way to do this would be loading the file.

Is there a limit as to how long something can block the audio computation? Will long functions in python triggered by a pattern potentially cause a hangup? I'm still learning my way around pyo.

[belangeo]

Is there a limit as to how long something can block the audio computation? Will long functions in python triggered by a pattern potentially cause a hangup?

Absolutely! No hard computation in function triggered by the audio thread (Pattern object runs on audio thread) or samples won't be computed fast enough for the soundcard's callback. If the sound files are dynamically generated, I think you should stick to SfPlayer, which does not need to load the entire file before reading it.