Hi all,
I have a few questions about PDA PD:
What is the minimum spec for running PD under Linux on a palmtop?
Has anybody seen a way to get information from a GPS device into PD?
My idea is to have a PDA running Linux + PD which can take acoustic samples at regular space/time intervals and tag them with GPS coordinates. Even the most general suggestions are welcome, but if somebody else has already figured this out, I'd really like to talk to you soon.
Best, Derek
derek holzer wrote:
Hi all,
I have a few questions about PDA PD:
- What is the minimum spec for running PD under Linux on a palmtop?
don't know the minimum butit runs fine on my sharp zaurus-sl5500 (200mhz or something)
no idea about the GPS stuff though
mfg.a.sdr IOhannes
On Wed, 2004-02-11 at 16:01, IOhannes m zmoelnig wrote:
derek holzer wrote:
Hi all,
I have a few questions about PDA PD:
- What is the minimum spec for running PD under Linux on a palmtop?
don't know the minimum butit runs fine on my sharp zaurus-sl5500 (200mhz or something)
How did you build and install pd for the zaurus? Is there a howto anywhere?
cheers
matthew
Matthew Yee-King wrote:
On Wed, 2004-02-11 at 16:01, IOhannes m zmoelnig wrote:
How did you build and install pd for the zaurus? Is there a howto anywhere?
i used guenter's PDa which can be found at http://gige.xdv.org/pd/PDa to get debian on my system i used a howto like http://mywebpages.comcast.net/clanwolfer/zaurus-debian-tcl-HOWTO.html note that there were some issues with devices on the compactflash (i used the SD but it is the same) as the filesystem normally mounts with "nodev" flags. you have to overwrite this in the fstab.
mfg.a.sdr IOhannes
cheers
matthew
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
- Has anybody seen a way to get information from a GPS device into PD?
i use gpsd for the gps and as there is no tcpip object in pd where one can send and listen from to the same port i get the data into pd with the following shellscript (which i call with giges shell object):
#!/bin/sh echo "x;" | nc localhost 2947 > ./data.txt & cat ./data.txt | nc localhost 3002 & sleep 0.1 killall -9 nc
the x is an option i build into gpsd to just send "lat long alt speed". i then use a netreceive 3002 in the patch to listen to for the data.
best
erich
On Thu, 2004-02-12 at 03:18, rat@telecoma.net wrote:
- Has anybody seen a way to get information from a GPS device into PD?
i use gpsd for the gps and as there is no tcpip object in pd where one can send and listen from to the same port i get the data into pd with the following shellscript (which i call with giges shell object):
#!/bin/sh echo "x;" | nc localhost 2947 > ./data.txt & cat ./data.txt | nc localhost 3002 & sleep 0.1 killall -9 nc
the x is an option i build into gpsd to just send "lat long alt speed". i then use a netreceive 3002 in the patch to listen to for the data.
Hi Erich,
At a quick glance, it seems your script would be better written thusly:
#!/bin/sh echo "x;" | nc localhost 2947 | nc localhost 3002 & sleep 0.1 killall -9 nc
I think there's no need for the intermediate data.txt. If you want to chain commands together, you should use '&&' instead of '&' - '&&' tells sh to only continue to the next command if the errorlevel of the previous command is 0. A single '&' causes the first process to be run in the background and the second process to run immediately, which could lead to reading from the file before it is written, which is probably not what you want. (ie, if the connect takes a long time for some reason, there'll be old data in data.txt)
Forgive me if I'm barking up the wrong tree!
The 'killall -9' at the end is a bit evil...
Nick :-)
On Thu, 2004-02-12 at 10:11, Nick Morrison wrote:
#!/bin/sh echo "x;" | nc localhost 2947 | nc localhost 3002 & sleep 0.1 killall -9 nc
The 'killall -9' at the end is a bit evil...
Ah. If your /bin/sh is a real sh shell, you could try:
kill jobs -ls
... instead of the killall line. Note that they are backticks (` and not ').
Nick
hi nick,
thank u for your modification :-) . i m not at all an experienced scripter/programmer as u could see
- but it worked.
what could i use instead of the "evil" killall -9 ?
best
erich
On Thu, 12 Feb 2004, Nick Morrison wrote:
On Thu, 2004-02-12 at 03:18, rat@telecoma.net wrote:
- Has anybody seen a way to get information from a GPS device into PD?
i use gpsd for the gps and as there is no tcpip object in pd where one can send and listen from to the same port i get the data into pd with the following shellscript (which i call with giges shell object):
#!/bin/sh echo "x;" | nc localhost 2947 > ./data.txt & cat ./data.txt | nc localhost 3002 & sleep 0.1 killall -9 nc
the x is an option i build into gpsd to just send "lat long alt speed". i then use a netreceive 3002 in the patch to listen to for the data.
Hi Erich,
At a quick glance, it seems your script would be better written thusly:
#!/bin/sh echo "x;" | nc localhost 2947 | nc localhost 3002 & sleep 0.1 killall -9 nc
I think there's no need for the intermediate data.txt. If you want to chain commands together, you should use '&&' instead of '&' - '&&' tells sh to only continue to the next command if the errorlevel of the previous command is 0. A single '&' causes the first process to be run in the background and the second process to run immediately, which could lead to reading from the file before it is written, which is probably not what you want. (ie, if the connect takes a long time for some reason, there'll be old data in data.txt)
Forgive me if I'm barking up the wrong tree!
The 'killall -9' at the end is a bit evil...
Nick :-)
-- Nick Morrison nickm@internode.com.au Network Operations Group, Internode
Proud to be the major sponsor of the Adelaide Fringe
Thanks everybody for your suggestions and comments on this PDA thread. I think there were a lot of folks on the list that didn't even *know* that PD runs on PDAs, so that was a nice side effect ;-)
A few of you mentioned that PD might be "overkill" for the simple purpose of recording and tagging soundfiles. This is true, but my final idea depends on a certain amount of processing [not necessarily realtime] to be done to the sound recorded. In the end, I want my PDA to generate small algorithmic "compositions" using soundfiles it gathers.
So, a few more questions in this vein, if you don't mind:
- If I decide not to use PD, is there another fairly full-featured
recording and processing program that takes command-line arguments and also runs on PDAs? I am thinking of Ecasound in particular, but I don't know how much modification of the program is necessary to run it on a PDA processor.
- Does anybody know of a PDA-linux-audio specific site, forum, board or
list?
- 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?
- 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
On Sun, Feb 15, 2004 at 09:18:12PM +0100, derek holzer wrote:
- If I decide not to use PD, is there another fairly full-featured
recording and processing program that takes command-line arguments and also runs on PDAs? I am thinking of Ecasound in particular, but I don't know how much modification of the program is necessary to run it on a PDA processor.
Here's an message about ecasound on the iPaq running Familiar: http://eca.cx/ecasound-list/2002/03/0012.html
-- Marc
Hallo, derek holzer hat gesagt: // derek holzer wrote:
- If I decide not to use PD, is there another fairly full-featured
recording and processing program that takes command-line arguments and also runs on PDAs? I am thinking of Ecasound in particular, but I don't know how much modification of the program is necessary to run it on a PDA processor.
You might find interesting things on: http://www.core-sound.com/
ciao
Frank Barknecht _ ______footils.org__
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
On Tue, Feb 17, 2004 at 11:20:32PM +0100, guenter geiger wrote:
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.
Unless the goal is to record short samples, the ramdisk would get full very quickly. A good solution would be to compress while recording at low sample rate (22050/mono), in order to write to a removable media. But encoding is usually very cpu intensive for small cpus with only integer math, and there might be no encoder that uses integer math like some decoders do (Mad for mp3 and Tremor for Vorbis and Flac for Flac...). Actually, I'm not sure about the Flac format; does it encode using integer math, like decoding?
-- Marc
Hi all,
Thanks again for all the great suggestions. Espc the link to the test of Ecasound compiled for PDA.
Marc Lavallée wrote:
Unless the goal is to record short samples, the ramdisk would get full very quickly. A good solution would be to compress while recording at low sample rate (22050/mono), in order to write to a removable media.
Actually, the goal *is* to record very short samples. Perhaps the best solution would be script the PDA to record samples with the max time allowed by the RAM disk, then transfer them to Flash when the recording is complete.
Unfortunately, what I aim to do involves binaural recording, so every little bit of psychoacoustic audio info is important! So heavy compression or mono sound is out-out-out. Maybe Lame with something like a VBR maxing at 192 would be OK, to extend the max recordable time in the RAM. Which of course leads me to think about how well Lame runs on a PDA, and whether it is efficient to encode directly before writing to RAM.
Just to be sure: in encoding, how big a block is written to RAM before compressing? Or rather, how much RAM would need to be free as overhead using this scheme? Perhaps this is configurable? I will check the Lame command-line arguments. Or am I making a wrong assumption about the encoding process?
Best, Derek
On Wed, Feb 18, 2004 at 01:10:21AM +0100, derek holzer wrote:
Unfortunately, what I aim to do involves binaural recording, so every little bit of psychoacoustic audio info is important!
So you need lossless audio at high quality. The samples will be very small...
Just to be sure: in encoding, how big a block is written to RAM before compressing?
Small enough. That should not be a concern on recent PDAs.
Marc
On Tue, 17 Feb 2004, Marc [iso-8859-1] Lavall�e wrote:
On Wed, Feb 18, 2004 at 01:10:21AM +0100, derek holzer wrote:
Unfortunately, what I aim to do involves binaural recording, so every little bit of psychoacoustic audio info is important!
So you need lossless audio at high quality. The samples will be very small...
Just to be sure: in encoding, how big a block is written to RAM before compressing?
Small enough. That should not be a concern on recent PDAs.
That not, but I doubt that any non-trivial encoding solution that is using integer exists. There is an ogg/vorbis decoder, called Tremor, which is int based. dunno if it does encoding too.
Well, don't know. probably flash is fast enough for direct recording too. To be honest I never really tried.
Guenter
Hey G,
guenter geiger wrote:
Well, don't know. probably flash is fast enough for direct recording too. To be honest I never really tried.
Maybe we should ask the folks at Core Audio, who make a professional-grade, multichannel, 32 bit sound card for PDAs with Flash memory? I think they might say it is fast enough. But I haven't dissected their recording app yet to see if it "swaps" between RAM and Flash memory.
In short, I think it is probably OK, now that I have thought it through a bit...
best, D.
On Wed, 18 Feb 2004, derek holzer wrote:
Hey G,
guenter geiger wrote:
Well, don't know. probably flash is fast enough for direct recording too. To be honest I never really tried.
Maybe we should ask the folks at Core Audio, who make a professional-grade, multichannel, 32 bit sound card for PDAs with Flash memory?
Yes, that exactly what I had in mind, when saying that. I remember that I have written a small recording application once, but I just can't remember if it was able to record to flash. No way to try now, because they have stolen my iPaq's from my checked in baggage (hijos de puta), when flying back from ICMC.
Hope I get a new one soon.
I think they might say it is fast enough. But I haven't dissected their recording app yet to see if it "swaps" between RAM and Flash memory.
hmm, maybe there are some tricks, but for the long run it has to work somehow.
In short, I think it is probably OK, now that I have thought it through a bit...
right,
Guenter
best, D.
-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 16: "Assemble some of the elements in a group and treat the group"
hi,
Yes, that exactly what I had in mind, when saying that. I remember that I have written a small recording application once, but I just can't remember if it was able to record to flash.
as i am right now sitting here and having a linux ipaq w/ flash beside me and irec/iplay from guenter installed i just tried it. and it works. i'm having a cheap nearly noname flash card and i'm using the also cheap and nice pitech dual cf sleeve. the recording was clear and had no dropouts. ipaq is a compaq h3600 and i recorded 10 seconds.
esd also comes with recording facilities on the ipaq, btw. if someone needs a working copy of the esd core (without installing all of the gpe suite), he can just mail me. but alas there are some sample rate issues, so it works only partly (and since i only use parts of it this does not matter for me).
we are just having a kind of public beta test of an ipaq based piece here in oslo. more information at http://randomseed.org/sevenmileboots. it does not use pd/PDa, though.
so if someone is in oslo, just drop by at the kunstnernes hus.
lg martin
No way to try now, because they have stolen my iPaq's from my checked in baggage (hijos de puta), when flying back from ICMC.
Hope I get a new one soon.
I think they might say it is fast enough. But I haven't dissected their recording app yet to see if it "swaps" between RAM and Flash memory.
hmm, maybe there are some tricks, but for the long run it has to work somehow.
In short, I think it is probably OK, now that I have thought it through a bit...
right,
Guenter
best, D.
-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 16: "Assemble some of the elements in a group and treat the group"
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
attacksyour.net/pi
hi,
I've a question about installing PD in a iPaq H3600, may be it's not quite relevant to the list but I'm desperate to solve the problem.
I've installed GPE on Ipaq h3600 (no extra CF memory) I've got 16 mb internal flash memory and 15.8 mb used
wanna install 1.9mb PD from ftp://xdv.org/pub/gige/iPaq/PDa_armbin.tgz, not enough space
anyone experience in uninstall games or other useless app to free memory space or other method to solve the problem?
slimboyfatboyslim http://www.slimboyfatboyslim.org
slimboyfatboyslim wrote:
hi,
I've a question about installing PD in a iPaq H3600, may be it's not quite relevant to the list but I'm desperate to solve the problem.
I've installed GPE on Ipaq h3600 (no extra CF memory) I've got 16 mb internal flash memory and 15.8 mb used
wanna install 1.9mb PD from ftp://xdv.org/pub/gige/iPaq/PDa_armbin.tgz, not enough space
anyone experience in uninstall games or other useless app to free memory space or other method to solve the problem?
buy some memory on CF or SD and install it there. mfg.asd.r IOhannes
but i think for H3600, I need to get a SD/ CF jacket in order to add SD/ CF memory, but I've already got a PCMCIA jacket for WiFi so.......it seems not possible
“IOhannes m zmoelnig”於 2004 年 3 月 22 日，週一 01:13PM 提到：
slimboyfatboyslim wrote:
hi, I've a question about installing PD in a iPaq H3600, may be it's not quite relevant to the list but I'm desperate to solve the problem. I've installed GPE on Ipaq h3600 (no extra CF memory) I've got 16 mb internal flash memory and 15.8 mb used wanna install 1.9mb PD from ftp://xdv.org/pub/gige/iPaq/PDa_armbin.tgz, not enough space anyone experience in uninstall games or other useless app to free memory space or other method to solve the problem?
buy some memory on CF or SD and install it there. mfg.asd.r IOhannes
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
slimboyfatboyslim http://www.slimboyfatboyslim.org
On Mon, 22 Mar 2004, slimboyfatboyslim wrote:
��IOhannes m zmoelnig���� 2004 �~ 3 �� 22 ��A�g�@ 01:13PM ����G
slimboyfatboyslim wrote:
hi, I've a question about installing PD in a iPaq H3600, may be it's not quite relevant to the list but I'm desperate to solve the problem. I've installed GPE on Ipaq h3600 (no extra CF memory) I've got 16 mb internal flash memory and 15.8 mb used wanna install 1.9mb PD from ftp://xdv.org/pub/gige/iPaq/PDa_armbin.tgz, not enough space anyone experience in uninstall games or other useless app to free memory space or other method to solve the problem?
Well, experience, I always did it this way, but I can't exactly remember what to uninstall. gpe-soundserver would be a good candidate (at least you have to disable it). games too. Just check what is there, there are surely some applications that you can get rid off. Another possibility is to install pd onto the ramdisk.
Guenter
hi derek,
- What is the minimum spec for running PD under Linux on a palmtop?
a cheap old ipaq 36xx does (and has the same processor as the zaurus). you get them used on ebay and even if you get the battery exchanged (wolfsoft.de), they are cheaper than new ipaqs.
realtime synthesis crackels, yet playing and recording sound files is working fine - i just wonder if you need pd for such a trivial taks as described below - a perl script might be enough.
- Has anybody seen a way to get information from a GPS device into PD?
most gps devices output nmea data. that is simply 9600 baud 8N1 ascii data. you can connect the gps device to the ipaq using crossed over cables. once the hardware is connected you can tail /dev/ttySA0 and see what comes in (after some stty magic).
erich berger had success in getting the data into pd - but i don't remember how anymore. it was some nice little hack.
information about linux on ipaq is to be found at http://familiar.handhelds.org
cu martin
My idea is to have a PDA running Linux + PD which can take acoustic samples at regular space/time intervals and tag them with GPS coordinates. Even the most general suggestions are welcome, but if somebody else has already figured this out, I'd really like to talk to you soon.
Best, Derek
-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 118: "Make what's perfect more human"
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
attacksyour.net/pi
-
derek holzer -
Frank Barknecht -
guenter geiger -
IOhannes m zmoelnig -
Marc Lavallée -
martin pichlmair -
Matthew Yee-King -
Nick Morrison -
rat＠telecoma.net -
slimboyfatboyslim