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@peabody.jhu.edu mambo.peabody.jhu.edu/~karlmac