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@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
--
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
/////////////// http://pendler.klingt.org //////////////
\\\\\\\\\\\\\\\ http://oliver.klingt.org \\\\\\\\\\\\\\
////////////////////////////////////////////////////////
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
