Thanks for answering,
IOhannes, you were right, now it works fine.
What I did :
- enlarged the buffersize of readsf~
- increased audiobuffer (I'm at 100 ms, but I think I can go below)
- created a huge 8 channels audio file read by a [readsf~ 8 1e008], and It seems to be the more efficient method of the three points.
Thanks again.
Roman Haefeli <reduzierer@yahoo.de> a écrit : On Tue, 2007-03-27 at 11:02 +0200, IOhannes m zmoelnig wrote:
> david lemarechal wrote:
> > Hi List,
> >
> > I have to play simultaneously 8 large soundfile (about 30min at
> > 44,1kHz/16bit, e.g. about 70 Mb each in wav format) on 8 different outputs.
> >
> > I use readsf~ on Windows but audio drops out at every disk access (when
> > the Disk Acess LED of my
laptop blinks), and of course this occurs very
> > frequently... I can hear about one minute without drops, then it occurs
> > at a fixed frequency (which I didn't calculate exactly).
> >
> > I tried to load each files with a long delay, tried to defragment,
> > nothing change. I tried to change the bloksize flag, and the arguments
> > of readsf~, with no luck.
>
> make the buffer for readsf~ HUGE (like [readsf~ 2 1e8] or so)
> make the audiobuf in pd as big as possible.
> make your harddisk as fast as possible (reorganize it; buy a new one)
> if you have enough ram, you could also consider using a ramdisk.
>
> oh and: do the 8 soundfiles have to be played independently? or is it
> really just a kind of 8track soundfile (split into 8 mono files).
> if so, i would _highly_ suggest creating one big 8channel interleaved
> soundfile and play that one instead of
8 separate files.
> your harddisk heads will be thankful for not having to move from one
> file to the other every block.
>
>
> i don't think that there are "better" soundfile players out there (there
> are soundfile players with more (and less) features; but in your case
> they should behave very similar or worse).
>
> we have been using [readsf~] successfully with 24 channel soundfiles
> without any dropouts.
i can confirm that (though i tested only with 16 channels), but the
first thing i'd do, is to test with another multitrack-software, if your
system is the bottleneck or if pd is the cause of these problem.
personally i don't trust pd too much on windows. i had once a similar
problem on windows, which might be related: when recording 8 or more
channels with [writesf~], one or more soundfiles were empty afterwards
(44 bytes to be exact). this was only on windows. i tested on the
same
system under ubuntu and everything worked well. we solved the problem
then by using the pd-core from pd-extended, then it worked also on
windows. it could be, that this issue is completely unrelated to your
problem. but at least it could be interesting to know, that there _are_
cases, where pd is the source of the troubles and not a slow harddisk /
too less ram etc.
roman
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses.