[PD] Glitch

[oliver]

hi, mike !

i did a similar thing with an ESI gigaporthd+ (8 output channels) on a 
RPI B+ without any glitches or stutter and 100% stable. even used simple 
filtering for each channel in the chain. no crashes in a run of 8 months.

some thoughts:

1.) increase PD's audio buffer size (like already mentioned), i don't 
know my settings anymore but since i didn't need any "realtime" 
behaviour i vaguely remember setting it up high (like 200ms or so ...)

2.) play back from RAM when possible (probably not)

3.) try to run the patch without any external communiction stuff like 
MIDI/OSC etc., maybe there IS something wrong here.

4.) use a fast SD card (which i'm pretty sure you already do, but i just 
thought i'd mention it here)

5.) (probably too special): i too used [readsf~] but in a modified way, 
as i didn't read my 8 channel file as a whole from disk/card, but in 
small chunks with a [bang~] inside a subpatch with a higher blocksize 
than PD's own 64 sample blocksize (i guess mine was 512 samples or even 
1024). not sure if this really matters in terms of your audio dropouts 
though.

6.) keep the soundfile quality normal (44 khz / 16 bit)


and most important:

if you succeed in fixing your problem, please consider dropping a line 
to the list describing what you did, to spare other sound-artists hours 
of head-scratching ;-)

best !

oliver



michael strohmann wrote:
> the file i play back is a clean voice recording.
> ups,  i am actually using readsf~
> will try to record pd internally...
> 
> anybody has experienced that behaviour with ESI 6 Channel Interface?
> Cheers!
> mkl
> 
>>
>> On Wed, 2018-07-04 at 10:53 +0200, michael strohmann wrote:
>>>
>>> Hello!
>>> from time to time my patch produces this beautiful, but unwanted
>>> glitch. (audiofile attached)
>>
>> Sounds like I'm doing doing music. I wouldn't know how to identify the
>> glitch aspect of it. How does it sound without the glitch?
>>
>> Some suggestions to make such things a bit easier:
>> * Do not use compressed files to illustrate a glitch. It's hard to
>>    know what to attribute to the compression and what to the glitch.
>> * If possible, provide also an example of how it is supposed to sound.
>> * If possible, rather post links to your media files instead of
>>    attaching them to your mail. There is no point in every list member
>>    have their mail account filled with media files.
>>
>>> are there any ideas what could cause this behaviour?
>>
>> I would first figure out where the glitch happens. Is Pd actually
>> generating this sound or is Pd's audio playback glitchy? You can figure
>> this out by doing a recording from within Pd with [writesf~]. If the
>> result sounds OK, then you know that the glitch happens somewhere
>> between Pd and the sound card. If the result is glitchy, then the
>> glitch happens already within Pd, for instance because some object or
>> your patch is buggy.
>>
>>> i am running this on a RPi B+, using sfplay~ to playback a 4 Channel
>>> Audiofile.
>>
>> Why are you using [sfplay~] and not the built-in [readsf~]? Does the
>> glitch still appear when using [readsf~]?
>>
>>> the playback is triggered via a sensor/GPIO or via OSC.
>>
>> This hopefully doesn't matter.
>>
>>> restarting the RPi eliminates the glitch.
>>
>> Could be some sound card issue, but check the other things first.
>>
>> Roman
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
> 


-- 
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
/////////////// http://pendler.klingt.org //////////////
\\\\\\\\\\\\\\\ http://oliver.klingt.org  \\\\\\\\\\\\\\
////////////////////////////////////////////////////////