[PD] how to avoid (most/many/some) readsf~ dropouts

Dr. Greg Wilder gregwilder at orpheusmediaresearch.com
Mon Jul 14 18:51:36 CEST 2008

Matt Barber wrote:
>> Date: Sat, 12 Jul 2008 13:56:54 +0200
>> From: Damian Stewart <damian at frey.co.nz>
>> Subject: [PD] how to avoid (most/many/some) readsf~ dropouts
>> To: PD-List <pd-list at iem.at>
>> Message-ID: <48789C06.4030401 at frey.co.nz>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> hey,
>> one thing i've noticed with readsf~ using it in my own live-performance
>> sets is that doing this
>> [symbol blahblahblah.aif]
>> |
>> [open $1, bang(
>> |
>> [readsf~]
>> sometimes causes dropouts. but if you go
>> [symbol blahblahblah.aif]
>> |
>> [t b a]
>> |      \____
>> |           \
>> [del 50]    [open $1(
>> | __________/
>> |/
>> [readsf~]
>> then you remove (all/many/some) of the dropouts. i haven't extensively
>> tested this, but anecdotal evidence seems to suggest that it works.
> I think this is because the former method may not let the buffer fill
> before you start playing.  I usually don't like the second method,
> either, because of the 50 ms delay (which isn't much, but I'm finicky
> about that kind of thing).  Depending on the setup, I usually prefer
> something like the following:
>                   [loadbang]
>                    |
>                    | [r open]
>                    | /
>                   [open  file.ext (
> [0 (     [1 (    |
>  |          \__   |
> [t b f ]_____\ |
>  |               [readsf~ ]
> [s open]                |
>                            [s open]
> I hope things line up okay there... at any rate, you load the buffer
> at the beginning, or if your piece/performance has a master clock, a
> couple of seconds before you need it.  Then for rehearsal, if you need
> to stop the file you can use a trigger to reload it immediately.
> Also, if you need to play the file again, you can send the "open"
> message when the file is done playing.  This makes the whole process a
> little more "front-loaded," so that the soundfile is always "open" no
> matter what.  My intuition is that it's more robust than other schemes
> I've tried.  I haven't tested it very hard, though, as I've only ever
> needed up to 9-10 simultaneous 96k files... maybe it would be neat to
> find some old, slow hardware to see how far different methods can be
> pushed.  =o)
> More advanced for stopping would be something that fades out the sound
> with a [line~] over 20 ms or so, and then sends the stop message to
> [readsf~] after a comparable delay -- that way you won't get an
> annoying transient upon stop -- same deal with a fade in if you are
> starting in the middle of the soundfile, but without the delay.  I
> usually wrap the whole thing in an abstraction -- I keep three or four
> different ones lying around with different properties for different
> situations, and I'm happy to share with anyone who might find them
> useful.
> Thanks,
> Matt

Matt and Damian,

In working on a recent piece for marimba and 8-channel computer 
(24bit/88.2kHz), I consistently experienced intermittent clicks and 
audio dropouts -- even on high-end hardware running GNU/Linux. 
Increasing the readsf buffer and the time between file load (open) and 
playback (readsf) helped some, but not enough.  Since the premiere last 
month, I've been rebuilding the abstractions for better efficiency, but 
am still not happy with the results -- and before the soloist can safely 
tour the piece, I need to work out a more robust solution.

I've attached the latest version of my "basic" playback (w/fade) patch 
for suggestions/comments...  Unfortunately, your ascii patch didn't line 
up, would you mind posting an example patch that shows your method?


+1 215-764-6057 (office)
+1 215-205-2893 (cell)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 8-channel_playback_example.pd
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20080714/f8f2d29a/attachment.asc>

More information about the Pd-list mailing list