[Sugar-devel] TA with sensors

[Arjun Sarwal]

On Sat, Jan 3, 2009 at 1:18 AM, Walter Bender <walter.bender at gmail.com> wrote:
> Thanks for this background.
>
> I think that the try/exception mechanism is adequate for our needs. It
> will be otherwise trivial for me to add the sensor features to the
> main branch of TA... I'll add it to the next release.
>
> I wonder if there is a mechanism we can call upon (Sugar should
> perhaps provide this) that will tell us that we are being sent to the
> background so that we can only reinitialize when we go away and come
> back? It seems that for every call to the sensor, it is a large
> overhead to incur...
>

There are signals in Sugar that are fired when an Activity becomes the
background Activity or foreground Activity (I've used these in Measure
code). It seems like a good idea to explore to keep the capture device
ON while TurtleArt is the active Activity and leave the audio device
when Activity is in background and then  re-initialize it when
TurtleArt becomes the active Activity.

> -walter
>
> On Fri, Jan 2, 2009 at 2:25 PM, Arjun Sarwal <arjunsarwal at gmail.com> wrote:
>> Hello Walter,
>>
>> Thank you for the new year wishes. Best wishes to you too for the new
>> year! (hope you received my card too)
>>
>> A few points regarding adding sensor support
>>
>> * Calls to Alsamixer to set the DC mode on/off will result in an
>> exception on one's normal laptop. This is because the DC mode controls
>> don't exist in the Alsamixer of a normal laptop (even sugar emulation
>> makes calls to the laptop's default alsamixer)
>>
>> * I had put in initializations before each call to the sensor because
>>  - user may switch to another Activity  in between a session of Turtle
>> Art -- the other Activity  may use the laptop's sound device. The
>> other Activity may alter the sound device settings.
>>  - unless a call for sensor input is being made, I didn't want to keep
>> the capture device active.
>> The capture device can be thought to be in a state of 'recording
>> sound' when one is getting sensor input data, hence only one
>> Activity/program can have access to it at one time.
>> However, any suggestions you may have on the above implementation
>> would be very welcome.
>>
>>
>> * If it helps, I am summarizing approximately the changes  I made in
>> TurtleArt to add sensor support and some relevant lines to look at
>> within the TA with Sensors code that I had made for the earlier (non
>> SVG version of TAwithSensors):
>> Referring to the  version of the online git tree ('Initial import')
>> (http://dev.laptop.org/git?p=users/arjs/TurtleArtwithSensors;a=tree;h=3f22f9f86d60f6160268c52009273eba82dba465;hb=3f22f9f86d60f6160268c52009273eba82dba465)
>>
>> - audiograb.py as an additional file was included completely
>> - talogo.py :
>> (note that lines 8 and 9 in this version of git tree would need to be
>> changed to
>> from numpy.oldnumeric import *
>> from numpy.fft import *  )
>> lines 8,9,11,12 were added
>> lines 366 onwards till the end have been added
>> -tasetup.py: lines 47 to 51 to account for the additional sensor
>> blocks in the UI
>>
>> As you can see from the code of talogo.py , the approach involves a
>> lot of painful starting the whole gstreamer pipeline, getting one
>> sample then stopping the pipeline. An overkill for getting just one
>> sample, but there is no way unless python alsa audio is included in
>> the build system. The approach with python alsa audio is work in
>> progress here (
>> http://dev.laptop.org/git?p=users/arjs/TurtleArtwithSensors;a=tree )
>>
>> I want to work on incorporating sensor support into the SVG version of
>> TA that you have made, but my current day job isn't leaving me any
>> time these days to do anything else. I will get to it as soon as I get
>> the opportunity, but if in the meanwhile you get a chance to do it -
>> it'd be great.
>>
>> Please let me know if I can help further.
>>
>> Kind Regards
>> Arjun
>>
>> On Fri, Jan 2, 2009 at 3:18 AM, Walter Bender <walter.bender at gmail.com> wrote:
>>>
>>> I've begun folding TA with sensors into TA. I use an exception to
>>> catch the calls to set DC Mode in Alsamixer, so it seems to run fine
>>> on my normal laptop using the mic input. But when I look at the logs,
>>> it seems that there is a lot of initialization that happens with every
>>> call to the sensor. Is that all necessary? Can we just check for
>>> changes after the first time?
>>>
>>> -walter
>>>
>>>
>>>
>>>        # test to see if DC Mode is enabled
>>>        try:
>>>            self.dcmode = Mixer('DC Mode Enable')
>>>            self.bias = Mixer('V_REFOUT Enable')
>>>            self.has_dcmode = True
>>>        except:
>>>            print "DC Mode unavailable"
>>>            self.has_dcmode = False
>>>
>>>
>>>
>>> Walter Bender
>>> Sugar Labs
>>> http://www.sugarlabs.org
>>
>>
>>
>> --
>> Arjun Sarwal
>>
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>