On Sun, 15 Feb 2004, derek holzer wrote:
- In PD, I assume that writing a sound to file is less prone to
clicks-and-cuts on a minimal system such as a PDA than playing to DAC. Is this correct?
Hi,
Recording sound on handhelds is very dependent on where you write it too. Flash is terribly slow, so you would have to write it to the ramdisk, and then copy it to flash.
ABout the clicks. In general PDa can do realtime signal processing (thats what its all about, I only changed the implementations of the signal processing objects). You have to think of the handhelds like the old notebooks, which means that there are problems with the sound drivers (under familiar linux especially).
One time I set up a new system, and it didn't run at all. Until I discovered that the system log daemon eats up all CPU. This was because all the debugging output from the sounddriver was compiled in. With some tweaking (adjusting -blocksize and enabling -rt) you normally get reliable operation even with the 200MHz devices. Of course the amount of processing is limited.
Then the 8 sec limitation of soundfiles is due to the control of reading/writing. I have 13 bits available to represent numbers higher thatn 1, this means 2^13 = 8192. The tabread counts in milliseconds (incompatible with upstream pd !!), which means 8192 milliseconds. This restriction does not apply to reading and writing to files. For writing you might be restricted by the amount of RAM you have, if writing to flash directly is too slow.
Guenter
- Guenter mentioned that max soundfile array size in PDa is 8 secs.
Does that only has to do with arrays which are being accessed? Or is that the max size that PDa can write to "disk" [i.e. Smart Flash memory] as well [also in a non-realtime situation]?
- Any idea if things like LADSPA plugins work on a PDA? [Also in
non-realtime mode.]
TIA! Derek
-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 44: "Discard an axiom"
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list