Hello,
I would like to know if the low-latency patches for the linux kernel improve the reliability of the disc i/o objects (readsf~ writesf~ sfread~ etc..)
I have not made an extensive testing but with all of them, despite having some SCSI stuff and decent CPUs, I get cliks and pops even with a few tracks (8 monos or so).
I tried different amounts of buffer without managing to get a reliable solution, with the pd audiobuf setting and with the buffer arg of readsf~ In fact I know that I can read easily more than 24 monos tracks with "broadcast2000" which is a multitrack recorder for linux... Why cannot get this kind of performance with PD ?
So 1) have you the same poor performance with PD disc i/o objects ? 2) Is it specific to pd linux ? 3) Do i set something not as it should ? 4) Is it because of no special optmisation in pd for disc i/o ? 5) how much tracks can you play on which hardware ? 6) Does The patchs for the linux kernel solves the problem, some facts ?
Thx for any help,
Linium
So 1) have you the same poor performance with PD disc i/o objects ? 2) Is it specific to pd linux ?
No, quite difficult to get good results unter WinNT too. (And Win98, of course.)
- Do i set something not as it should ?
- Is it because of no special optmisation in pd for disc i/o ?
- how much tracks can you play on which hardware ?
On WinNT (PII 400MHz, 64MB RAM, S/P-Dif-Interface, SCSI HDs) I can hardly play 4 mono files without any pops (it would work when only playing files, the soon I start to do anything else with pd - especially gem ! - the result is horrible). I know, there are many people complaining about Win in general, but other software (Cubase VST, Samplitude...) does the job... so, same problem as on linux
- Does The patchs for the linux kernel solves the problem, some facts ?
Thx for any help,
Linium
Olaf
On Sat, 3 Mar 2001, Linium wrote:
In fact I know that I can read easily more than 24 monos tracks with "broadcast2000" which is a multitrack recorder for linux... Why cannot get this kind of performance with PD ?
So 1) have you the same poor performance with PD disc i/o objects ? 5) how much tracks can you play on which hardware ?
I am able to read 24 tracks easily, writting is another issue. What computer do you have ? Its on a 500 Mhz, IDE disk with DMA enabled.
- Is it specific to pd linux ?
- Do i set something not as it should ?
- Is it because of no special optmisation in pd for disc i/o ?
I am not sure about the builtin objects (readsf~ writesf~), but I can't think of any further optimization in sfread~ and sfwrite~. (Doesn't mean that there is no way to do it faster ...)
Guenter
- Does The patchs for the linux kernel solves the problem, some facts ?
Thx for any help,
Linium
There are reports from around UCSD that you can read one 8-channel SF with no trouble but can't begin to read 8 1-channel ones separately on a "reasonable" IDE machine. I'm hoping to get a chance to look at this (and a student is also threatening to get involved.) So the situation might improve soon.
cheers Miller
On Sun, Mar 11, 2001 at 09:19:54PM +0100, guenter geiger wrote:
On Sat, 3 Mar 2001, Linium wrote:
In fact I know that I can read easily more than 24 monos tracks with "broadcast2000" which is a multitrack recorder for linux... Why cannot get this kind of performance with PD ?
So 1) have you the same poor performance with PD disc i/o objects ? 5) how much tracks can you play on which hardware ?
I am able to read 24 tracks easily, writting is another issue. What computer do you have ? Its on a 500 Mhz, IDE disk with DMA enabled.
- Is it specific to pd linux ?
- Do i set something not as it should ?
- Is it because of no special optmisation in pd for disc i/o ?
I am not sure about the builtin objects (readsf~ writesf~), but I can't think of any further optimization in sfread~ and sfwrite~. (Doesn't mean that there is no way to do it faster ...)
Guenter
- Does The patchs for the linux kernel solves the problem, some facts ?
Thx for any help,
Linium
Le Sun, 11 Mar 2001, guenter geiger a écrit :
So 1) have you the same poor performance with PD disc i/o objects ? 5) how much tracks can you play on which hardware ?
I am able to read 24 tracks easily, writting is another issue. What computer do you have ? Its on a 500 Mhz, IDE disk with DMA enabled.
I have a dual 400 with scsi and fast hardisc and 128 mb. performances reported were with the standard readsf~ object.
- Is it specific to pd linux ?
- Do i set something not as it should ?
- Is it because of no special optmisation in pd for disc i/o ?
I am not sure about the builtin objects (readsf~ writesf~), but I can't think of any further optimization in sfread~ and sfwrite~. (Doesn't mean that there is no way to do it faster ...)
Guenter
Meanwhile I have tested the sfread~ and sfplay~ provided in your
external lib, and I have to say they seem to work better.
EXCEPT that they load everything in ram, aren't they ?
I have just made the test to open 8 tracks or so with sfread~ and pd memory
size kept growing until it dies with "broken pipe".
Regards,
Linium
On Tue, 13 Mar 2001, Linium wrote:
I have a dual 400 with scsi and fast hardisc and 128 mb. performances reported were with the standard readsf~ object.
Should not be a problem then.
<snip> > Meanwhile I have tested the sfread~ and sfplay~ provided in your > external lib, and I have to say they seem to work better. > EXCEPT that they load everything in ram, aren't they ? > I have just made the test to open 8 tracks or so with sfread~ and pd memory > size kept growing until it dies with "broken pipe".
none of them read the data into memory.
sfread~ uses mmap, which made it very simple implementing a varyspeed player. It actually should not crash, ( I couldn't get it to crash with 8 stereo files of 3min each), but it starts swapping, because it makes linux believe that the soundfiles are in memory, but just swapped out. so, well it does kind of use the memory, but by expanding the virtual memory. Your crash may be a bug in the kernel too. I have to do extensive testing which probably will not happen because my brain is full of other things.
sfplay was written by Winfried Ritsch in order to optimize playback of multiple files, so it is the one that you probably want to use. (it is the one I am using if I want to playback multiple files).
the difference between sfplay~ and the builtin readsf~ is, that readsf~ is multithreaded and guaranties not to block pd .... maybe thats a problem ?
Guenter
-
guenter geiger -
Linium -
Miller Puckette -
Olaf Matthes