[PD] harddisc activity blocks sound playback

Karl MacMillan karlmac at peabody.jhu.edu
Mon Sep 24 16:14:11 CEST 2001


My understanding is that the RME has the number of fragments set at 2 as a
hardware property. I don't see why the drivers couldn't do more buffering,
however.

Karl

On Sun, 23 Sep 2001, Miller Puckette wrote:

> Hi all,
>
> I don't understand why 64 sample buffers should be a problem for RME
> since you should be able to use many buffers ("fragments") to set
> the latency to a reasonable value.  But perhaps I'm mising something...
>
> cheers
> Miller
>
> On Thu, Sep 13, 2001 at 02:35:45PM +0200, guenter geiger wrote:
> >
> >
> > On Thu, 13 Sep 2001, IOhannes m zmoelnig wrote:
> > > this should definitely rock !
> > > note, that i do not remember having problems with a rme-9652 and
> > > kernel-2.4.3 (or something),
> > > although i had to compile the kernel myself then.
> > > i am sure, that i could play-bac 2 files at least.
> > >
> > > which soundfile-player do you use ?
> > > under linux i definitely suggest using miller's "readsf" instead of
> > > zexy's "sfplay~" !!
> > > could this be the problem ?
> >
> > I don't think so.
> > I'm not sure if the pd-0.34 has the same thing, but the buffersize for
> > the RME is changed to use 64 samples (the smallest buffer you can get
> > for the rme), no matter what buffersize you request.
> >
> > Linux without the low latency patches isn't suited for this short buffers
> > when doing harddisk I/O.
> >
> > Even with lowlatency you are living on the edge with this setting.
> >
> > The only way I found to change this was editting s_linux.c
> >
> > Guenter
> >
> >
>

---------------------
Karl W. MacMillan
Computer Music Department
Peabody Institute of the Johns Hopkins University
karlmac at peabody.jhu.edu
mambo.peabody.jhu.edu/~karlmac




More information about the Pd-list mailing list