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
this sounds very much like a buffering problem. Try to increase Pd's latency in the audio settings and see if the problem persists. When I'm working with Raspberry Pi + cheap USB soundcards I sometimes have to increase the latency up to 100 ms to get rid of occasional glitches when the CPU load is high.
Gesendet: Mittwoch, 04. Juli 2018 um 12:44 Uhr Von: "michael strohmann" itsnotfair9@gmail.com An: pd-list@lists.iem.at Betreff: Re: [PD] Glitch
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
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
-
Christof Ressi -
michael strohmann -
oliver