Hello all,
I'm new to PD and this graphical programming thing but managed to get things installed on my Red Hat 7.0.1J (Kernel 2.2.16-22) Linux machine. First something to that point: I too, as the documentation mentions, had problems with "libtcl.so" and "libtk.so" The proffered solution (ln -s libtk8.3.so libtk.so etc.) did not work however because pd (pd-033PATCH1) was looking specifically for libt*8.0. Installing the rpm instead of compiling the .tar.gz distribution solved the problem though.
Anyway, that wasn't my main point. I'm having (only!) two problems at the moment. The first is with latency. I see in the docs talk about 8ms, 5ms, 3ms latency and how you can improve these lamentable figures (?!). At the moment I'm looking at about 1000ms latency when playing sound files :-( I'm using the OSS drivers and don't really have much choice about that because I made the mistake of buying a turtle beach multisound pinnacle card a few years ago. This card has never been well supported and it was only with extremely high curse factor that I got the bugger playing at all under Linux, but I can assure you now that there doesn't appear to be any latency when, for example, I press the play button on 'snd' from CCRMA. When I trigger a sound in PD with the mouse or keyboard however, I get about a 1 second time lag before the sound starts. And this no matter what combination of -audiobuf -fragsize -blocksize I care to use. Any ideas anyone?
The second problem is with sfplay~ and its open message. When I 'open' a longish file (that every other sound player seems to like well enough) without setting the optional header size etc. and then try to play it with 'sfplay~ 2 1000', I get no output. When, however I give arguments like "open 0 40 2 2 l" it plays ok, but of course skipping some samples and creating a click. Do I really have to work out how big my header is etc. to get this object to work? Any hints out there?
Apologies in advance for the verbosity and perhaps arcane English of this mail. All the best,
Michael
Michael Edwards Tel: Office: +43 (0)662 6198-5125 Universitaet Mozarteum Home: +43 (0)662 844462 Fuerbergstrasse 18-20 Mobile: +43 (0)699 11 686 441 A-5020 Salzburg Email: mailto:m@michael-edwards.org Austria Web: http://www.michael-edwards.org ________________________________________________________________________
Michael Edwards wrote:
The first is with latency. I see in the docs talk about 8ms, 5ms, 3ms latency and how you can improve these lamentable figures (?!). At the moment I'm looking at about 1000ms latency when playing sound files :-( I'm using the OSS drivers and don't really have much choice about that because I made the mistake of buying a turtle beach multisound pinnacle card a few years ago. This card has never been well supported and it was only with extremely high curse factor that I got the bugger playing at all under Linux, but I can assure you now that there doesn't appear to be any latency when, for example, I press the play button on 'snd' from CCRMA. When I trigger a sound in PD with the mouse or keyboard however, I get about a 1 second time lag before the sound starts. And this no matter what combination of -audiobuf -fragsize -blocksize I care to use. Any ideas anyone?
Michael,
I too fought with this card for a while. Don't know if this is the root of your problem...
Don't know if you have the driver files. If not, go to Andrew Veliath's site at http://atv.ne.mediaone.net/linux-multisound/
and download the driver source archive. In there is basically a 'readme' called MultiSound, which describes options you can pass to the kernel module (it is better, I think, to load the soundcard driver as a module using 'insmod' rather than hard-coding it into the kernel for this very reason). One option you can set is 'fifosize', the Pinnacle's firmware buffer size. By default I seem to remember it's set to something really high, but you can reduce it by specifying when you do 'insmod' (I'd advise you read the MultiSound file carefully).
In my machine I just set up a script to do the necessary insmod etc at startup.
Hope that helps.
Nick
hi,
- from object arguments and 'open' message format you quote
I imply you are using readsf~ (as in the subject) and not sfplay~.
- From the values used in your open message I imply you are using
a .wav soundfile.
- The readsf~ (and soundfiler) objects assume there is a 'data' chunk
right after a 'fmt' chunk in a .wav file. If your sound was saved in wavelab or some such windowish app, there could be another chunk in between, like a 'PAD' chunk. If so, then readsf~ reads only from this extra chunk (which is usually all zeros) -- and you 'really have to work out how big your header is'...
Krzysztof
Michael Edwards wrote: ...
The second problem is with sfplay~ and its open message. When I 'open' a longish file (that every other sound player seems to like well enough) without setting the optional header size etc. and then try to play it with 'sfplay~ 2 1000', I get no output. When, however I give arguments like "open 0 40 2 2 l" it plays ok, but of course skipping some samples and creating a click. Do I really have to work out how big my header is etc. to get this object to work? Any hints out there?
You are basically saying that the WAVE parsing is wrong (as it so often is in unix apps!). It takes about three extra lines of simple code to jump over unknown chunks, and then ~all~ WAVE files (e.g those produced by Csound including the PEAK chunk - which PD could find very useful anyway!) can be read by PD. The WAVE spec requires that the data chunk is after the fmt chunk, so this simple skipping of unknown chunks will always work. In fact, there can be other chunks ~before~ the fmt chunk; it should not be presumed to be immediately after the RIFF<>WAVE<> elements.
I have some example files with the PEAK chunk on my "Soundcard Attrition Page", if anyone wants to experiment. There are also some examples with a 'long' header as used in CDP.
Richard Dobson
Krzysztof Czaja wrote:
- The readsf~ (and soundfiler) objects assume there is a 'data' chunk
right after a 'fmt' chunk in a .wav file. If your sound was saved in wavelab or some such windowish app, there could be another chunk in between, like a 'PAD' chunk. If so, then readsf~ reads only from this extra chunk (which is usually all zeros) -- and you 'really have to work out how big your header is'...
yes... I agree that it is basically as simple as putting some
while (strncmp(((t_wave*)buf)->w_datachunkid, "data", 4))...
loop afer line 252 of d_soundfile.c (need to adjust headersize inside that loop).
Krzysztof
Richard Dobson wrote:
You are basically saying that the WAVE parsing is wrong (as it so often is in unix apps!). It takes about three extra lines of simple code to jump over unknown chunks, and then ~all~ WAVE files (e.g those produced by Csound including the PEAK chunk - which PD could find very useful anyway!) can be read by PD. The WAVE spec requires that the data chunk is after the fmt chunk, so this simple skipping of unknown chunks will always work. In fact, there can be other chunks ~before~ the fmt chunk; it should not be presumed to be immediately after the RIFF<>WAVE<> elements.
...
well, not that simple, as this applies to PCM (format 1) wave files only. But to handle other formats there would need to be much more code patching anyway.
Krzysztof
I wrote:
yes... I agree that it is basically as simple as putting some
while (strncmp(((t_wave*)buf)->w_datachunkid, "data", 4))...
...
I just checked, and yes, the WAVE reading code doesn't skip over chunks correctly... I'll stick this on my dolist. I've never run into a WAV file with extra chunks, but I already had to do the equivalent for AIFF, which was a bear...
cheers Miller
On Tue, Jul 03, 2001 at 03:09:05PM +0100, Richard Dobson wrote:
You are basically saying that the WAVE parsing is wrong (as it so often is in unix apps!). It takes about three extra lines of simple code to jump over unknown chunks, and then ~all~ WAVE files (e.g those produced by Csound including the PEAK chunk - which PD could find very useful anyway!) can be read by PD. The WAVE spec requires that the data chunk is after the fmt chunk, so this simple skipping of unknown chunks will always work. In fact, there can be other chunks ~before~ the fmt chunk; it should not be presumed to be immediately after the RIFF<>WAVE<> elements.
I have some example files with the PEAK chunk on my "Soundcard Attrition Page", if anyone wants to experiment. There are also some examples with a 'long' header as used in CDP.
Richard Dobson
Krzysztof Czaja wrote:
- The readsf~ (and soundfiler) objects assume there is a 'data' chunk
right after a 'fmt' chunk in a .wav file. If your sound was saved in wavelab or some such windowish app, there could be another chunk in between, like a 'PAD' chunk. If so, then readsf~ reads only from this extra chunk (which is usually all zeros) -- and you 'really have to work out how big your header is'...
-- Test your DAW with my Soundcard Attrition Page! http://www.bath.ac.uk/~masrwd (LU: 3rd July 2000) CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 23rd February 2000)
-
Krzysztof Czaja -
Michael Edwards -
Miller Puckette -
Nick Fells -
Richard Dobson