[GEM-dev] sound + video : real time issues

Menno van der Woude mennowo at gmail.com
Mon Nov 14 10:09:32 CET 2011


On Windows, when on dual or more cores, you could also try to
(additionally) set the affinity of a process to a certain core. So one
pd instance has affinity with one or two or four cores, and another
with one or two or four other cores. This can be done in task manager,
processes, right click, set affinity. I am unsure if and how this
could be done on Linux.

Bye, menno

On Mon, Nov 14, 2011 at 4:32 AM, Hans-Christoph Steiner <hans at at.or.at> wrote:
>
> I think generally, for gem + audio patches, people run two instances of Pd, one for Gem and the other for the audio.  The audio instance has realtime priority, and the Gem one does not.
>
> .hc
>
> On Nov 13, 2011, at 10:17 PM, Ricardo Fabbri wrote:
>
>> Hi,
>>
>> I am building instalations/instruments which control sounds
>> through the webcam, using a color detector that I submitted to this
>> list a couple of days ago. Things work well, and I am just facing real
>> time/delay issues now.
>> When I try to generate sound with any pix
>> processing, I am getting jumps in the sound (like on/off sounds at
>> about 5-20Hz). Turning off any pix processing, the sound is then back
>> to normal, even if I show the raw video from the camera on a gemwin.
>> By pix processing I mean anything with even only 1 pass through the
>> image on the CPU. I am using a ps3eye camera, which makes things
>> better as it has a high framerate, but I still get interruptions in
>> the sound.
>>
>> Why is this lag in the sound? The image with the output of the pix
>> processing doesn't seem to be moving any slower with or without sound.
>>
>> What are your experiences in trying to get gem pix processing, video,
>> and DSP to work in real time? My application is interactive, so that I
>> really need the sound to be as smooth as possible. Here are some
>> factors I will investigate, let me know if they make any sense to you:
>>
>> - It could be just too much data, even a single pass on each pixel
>> could be causing delays/jumps. I could downsample the image prior to
>> any pix processing
>> - The kernel is too slow in processing the video stream; I tried '-rt'
>> with no success
>> - Perhaps there is a problem in Pd sound scheduling vs pix processing
>> - Perhaps its just the CPU. In fact, I used OSC to do the video on one
>> machine, send the parameters to a second machine which then processes
>> the audio there. This effectively solved the problem. Question is, is
>> this due to CPU or to another factor?
>>
>> I would really appreciate hearing ideas from you, as I am new to this.
>> Best,
>> Ricardo Fabbri
>> --
>> Linux registered user #175401
>> www.lems.brown.edu/~rfabbri
>> labmacambira.sf.net
>>
>> _______________________________________________
>> GEM-dev mailing list
>> GEM-dev at iem.at
>> http://lists.puredata.info/listinfo/gem-dev
>
>
>
> ----------------------------------------------------------------------------
>
> Computer science is no more related to the computer than astronomy is related to the telescope.      -Edsger Dykstra
>
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>



-- 
---
Muziek, weblog en zo meer:
www.indelucht.nl
---
A photo a day keeps the questions away:
www.whatkeepsmegoing.com



More information about the GEM-dev mailing list