[PD] jack - [udpreceive] - audio engine on
Hello, I'm having some troubles using the object [udpreceive] with jack. I reduced my patch to make it traceable. 1. start jack 2. start pd working with jack as audio engine 3. source patch: [toggle] - [metro 1] - [1( - [udpsend] connect [udpsend] to localhost (127.0.0.1) on a highport (12350) 4. destination patch: [udpreceive 12350] 5. turn on the audio engine After turning on the audio engine the GUI of the destination patch isn't updated any more (it still responds to the mouse but doesn't show the result of my clicking or patching). I'm not having the troubles working with ALSA and the load of my system is quite low (and I reproduced the problem on another machine): -- top - load average: 0.18, 0.12, 0.09 Cpu(s): 1.1%us, 1.3%sy, 0.0%ni, 97.1%id, 0.0%wa, 0.0%hi, 0.5%si, 0.0%st Mem: 2050720k total, 862196k used, 1188524k free,63984k buffers Swap: 4915880k total,0k used, 4915880k free, 506104k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 14xxx xxx 20 0 19924 3864 2284 S2 0.2 0:05.67 pd 14xxx xxx 20 0 32080 4976 4664 S0 0.2 0:01.43 jackd -- Thanks for any help. Wolfgang ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] jack - [udpreceive] - audio engine on
Does it still do that if you run the [metro] a lot slower than 1000/sec? No, then it's fine, but in my not simplified patch the [udpsend] object is (and has to be) triggered by the object [pack~] (where the output is called within every dsp-cycle) and shows the same behaviour as reported. lg Wolfgang ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] packOSC TimeTag realtime vs. logicaltime
Hello, I'm using a combination of [pack~] [packOSC] - transmission(UDP) - [unpackOSC] and a modified version of [unpack~] to send Audio over OSC. The OSC packages are sent as Bundles so a TimeTag is generated at the sender's side. I extended the [unpackOSC] object with another outlet where I'm getting the particular TimeTag of each Bundle. In the modified version of [unpack~] I evaluate these TimeTags with regards to dropouts in the transmission. My problem is that the TimeTags are not accurate, what I ascribe to the fact, that the TimeTag in [packOSC] is generated as real time instead of logical time. Using real time the TimeTag-Output is a function of the audiobuffersize (depending on the cpu load), so in my case, as the CPU-load is quite big, the values of the TimeTags are not useable for sequencing the datastream (as there are jumps in the TimeTag I always assume some packages got lost). As a workaround I established a sequence number, which is additionally transmitted in each Bundle. This is an appropiate solution, but it wouldn't be necessary if the TimeTag would be generated properly. Are my considerations conclusive? Wolfgang ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] packOSC BLOB
iirc, for the very project the decoding is done outside of Pd anyhow (on specialized hardware), so the problem of [unpackOSC] not knowing what to do with a blob is a minor issue here. (and the use of specialized hardware is the reason why data (low-resolution fixed-point numbers) should actually be packed in a blob rather than floating-point). The decoding should be done on a microcontrollerboard and in puredata too. The audio data will be sent over ethernet to the target device, there it should be decoded and played back. The problem lies at the ethernet layer, where only a 10Mbit/s wire is available. At a Samplingrate of 44100Hz and a word width of 32bit are only about 7 channels (without overhead,...) possible. So it would be fine to reduce the resolution from 32bit floating point to maybe 16bit or even 8bit fixed point (while 32bit floating point is still selectable in case of better hardware). Sending 16bit or 8bit samples over OSC (without losing the gained bit width (OSC-data-types are at least 32bit)) will require an arbitrary alignment of the bits within each OSC-data-argument, where BLOB comes into play. i still think (see above) that even [packOSC] cannot provide a consistent interface to pack blobs into an osc message that is sufficiently more simple to use than manually constructing OSC messages. Thanks Wolfgang ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] packOSC BLOB
Hello, For sending audio efficiently over OSC I would need an OSC-BLOB. Unfortunately the packOSC object supports no OSC-BLOBs. Is there any possibility to send BLOBs? ciao Wolfgang ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] signal / message
Hello, What's the best way to convert a signal into a message? There are possibilities like snapshot~ or vsnapshot~, but they are not accurate. The error they produce when you convert into a message and reconvert to a signal (with sig~, line~ or vline~) is clearly audible. ciao Wolfgang ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] packOSC problems sendtyped T,F,I,N
Hello, I'm having some troubles using the packOSC object. Especially sending types True, False, Infinitum and Nil. It's not possible to send those types alone in one message, e.g.: sendtyped /address/1 TF fails as well as: sendtyped /address/1 iTF 23. Only if those types occure within or before an integer (or float or string) it's possible to send them, e.g.: sendtyped /address/1 iTFi 31 23 or sendtyped /address/1 TFi 22. Error Message: packOSC: According to the type tag I expected more arguments. packOSC: Problem writing address. packOSC: usage error, write-msg failed. ciao Wolfgang ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] signal / message
Jaime Oliver wrote: well, the question is for what reason are you doing it? I want to send audio data packed in OSC messages/bundles over Ethernet. I think it is better to get some features from say sigmund~ and use those to control or recreate, but i don't know what you want I guess in my case it's better to work with exact audio data, an estimation would limit applications on the receiver side. Wolfgang J On Sun, May 10, 2009 at 8:54 AM, Roman Haefeli reduzie...@yahoo.de wrote: On Sun, 2009-05-10 at 17:29 +0200, Wolfgang Jäger wrote: Hello, What's the best way to convert a signal into a message? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] signal / message
Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: an easier way is to use [pack~] and [unpack~] from zexy. those convert a signal vector (one block of audio samples) to a list of floats and vice versa. if you want to have a stream of floats instead of lists, use [drip]. Or use [tabsend~] and read out the table between dsp cycles. Ciao Thanks a lot, I'm definitly going to try this, even if my computer seems to be a little bit too slow. Wolfgang ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
