[PD] file access audio glitches

Phil Stone pkstone at ucdavis.edu
Sun Oct 14 01:46:57 CEST 2007


Roman Haefeli wrote:
> hi phil
>
> afaik, this affects every pd (yet) on every os, since this is due to
> pd's design. all objects i know, that do fileIO (except the threaded
> soundfiler),

Ah, the legendary threaded soundfiler.  I tried to track this down once, 
but had no luck.  I remember something about it having a problem with 
audio files, but I have always wondered if it would (or at least could 
be made to) work well for non-audio data loads.

>  do block pd's processing until they will have finished
> their task. if you have something like this:
>
> [t b b]
> |     |
> |     [read somefile(
> |     | 
> |     [somefilereadingobject]
> |
> [print]
>
> the bang will be printed only after [somefilereadingobject] has finished
> reading the file. you are probably going to say, that this is odd, but
> that is how pd actually/unfortunately works.
>   

I was afraid that this was so.  Too bad.  I could see it being necessary 
for audio loads, but non-audio file I/O, at least, should be able to run 
in the background.

> the only way to overcome this issue (beside rewriting pd or writing new
> objects) is to put everything into ram in advance. i don't know, what
> kind of files you are reading, but there are quite a few objects, that
> can read and store textfiles, as there are quite many for soundfiles as
> well. 
>   

Do you know if the caching effect I described (where second and later 
accesses to files tend not to glitch) work across OSes, and if so, can 
it be relied upon?  I.e., if I load everything I need at least once, 
will it be ram-cached?  I don't know anything about this part of *nix 
(OS X or other flavors), never mind Windows.  I would guess that it 
probably only helps for small files anyway, because if the load from ram 
takes long enough, there will still be dropouts.

Does anybody know if ram disks are possible on OS X?

> if you really don't know in advance, which file you are going to open,
> then you could probably build some kind of an 'asynchronous' filereader
> patch, that runs in another (-nrt) instance of pd, that passes the data
> over a network socket ([netsend]/[netreceive]) to your audio
> patch/instance. beware, that [netsend] is not dropout safe as well, but
> as long as you only have the [netreceive] in your audio patch, this
> won't be an issue.
>   

That's an intriguing idea.  OSC could also probably be used for 
loading/saving patches and such, though [netsend][netreceive] would be 
more versatile.

> roman
>
> p.s.: it's probably the right moment now to mention, that the nova
> project addresses such issues.   
>   

I hope for great things from that project.  An asynch PD would be awesome.


Thanks for writing, Roman.


Phil

>
>
> On Sat, 2007-10-13 at 12:02 -0700, Phil Stone wrote:
>   
>> Hi everybody,
>>
>> I'm not even certain this is a problem across all operating and sound 
>> systems; it certainly is a problem on my setup with OS X.  Any sort of 
>> file access has the possibility (*probability* on the first access to a 
>> given file) of causing audio dropouts.  For instance, if I use [tunetof] 
>> to load in new scale data, the first time I access a given scale file, 
>> there's a dropout.  Subsequent accesses of that same file don't seem to 
>> cause dropouts.
>>
>> I currently just switched to PD 0.40.3-extended, but this has been 
>> happening for as long as I can remember -- several versions back.
>> Is this behavior common across PD, or just something intrinsic to OS X 
>> or my sound hardware?
>>
>> Also, is it some kind of file caching that's keeping subsequent access 
>> to a file from causing dropouts?
>>
>>
>> Phil Stone
>> pkstonemusic.com
>>
>>
>>
>> _______________________________________________
>> PD-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>     
>
>
> 		
> ___________________________________________________________ 
> Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
>
>   





More information about the Pd-list mailing list