PlaySound issue

Hi!
I'm trying to play two different sound when my wifi card get/release
an ip address from udhcpc.
To get these events I use rtnetlink.
I have two issues, the first is that when udhcpc get a lease rtnetlink
signals a new address, del address and new address again, this does
not happen with dhcpcd, but may be OT there.
The second is related to PlaySound.  As of the tree grouped events
PlaySound is called fast.
As afaik only one sound at time is permitted I want to check for dbus
error, stopping the player if
"org.freesmartphone.Device.Audio.AlreadyPlaying" is raised.
The problem is that the above error comes out only some time while the
most recourring error is "Could not open audio device for playback.
Device is being used by another application."
"org.freesmartphone.Device.Audio.PlayerError".

I'm using debian sid with "original" 5.1 FSO and QT library dbus module.

Regards

    Nicola

Re: PlaySound issue

> As afaik only one sound at time is permitted I want to check for dbus
> error, stopping the player if
> "org.freesmartphone.Device.Audio.AlreadyPlaying" is raised.
> The problem is that the above error comes out only some time while the
> most recourring error is "Could not open audio device for playback.
> Device is being used by another application."
> "org.freesmartphone.Device.Audio.PlayerError".

wouldn't it be faster and more efficient, to simply catch the error  
instead and act accordingly?

Re: PlaySound issue

On Wed, Jul 1, 2009 at 6:05 PM, arne anka<openmoko <at> ginguppin.de> wrote:
>> As afaik only one sound at time is permitted I want to check for dbus
>> error, stopping the player if
>> "org.freesmartphone.Device.Audio.AlreadyPlaying" is raised.
>> The problem is that the above error comes out only some time while the
>> most recourring error is "Could not open audio device for playback.
>> Device is being used by another application."
>> "org.freesmartphone.Device.Audio.PlayerError".
>
> wouldn't it be faster and more efficient, to simply catch the error instead
> and act accordingly?

Yes! but actually it acts very strange as the play upsound, play
downsound/ play upsound results in playing "downsound" so I hear the
same sound for up/down events :)
I cannot guess now what's happen if an incoming call arrives while I
use PlaySound!

    Nicola

Re: PlaySound issue

The PlaySound semantics are that the same sound is only permitted to be played 
once. Since we use Alsa, we have to rely on the distribution configuration of 
it though. From the viewpoint of the framework, we don't want to get into 
sample mixing business, hence we recommend people to enable dmix by default in 
their alsa configuration.

:M:

Re: GSM firmware moko11, kernel and boot loader

On Tuesday 30 June 2009 14:41:45 Luca Capello wrote:
> I can reproduce the error I get with my old Debian on a new installation
> with kernel 2.6.29.  Again, if I start Zhone from an SSH session,
> everything is OK, but from ~/.xsession I always get D-Bus timeout errors

My theory would be that during the X start a lot of things happen in parallel, 
hence D-Bus calls take longer.

I strongly recommend that you do not use Debian's stock dbus, but rather a 
patched version that allows for longer timeouts. The upstream dbus 
configuration _is_ broken in that regards. And yes, the upstream dbus people 
are aware of that, but they are so PC-centric that they are not interested in 
fixing that :(

You can grab the patches from OE.

:M:

Re: PlaySound issue

On Wed, Jul 1, 2009 at 7:42 PM, Michael 'Mickey'
Lauer<mickey <at> vanille-media.de> wrote:
> The PlaySound semantics are that the same sound is only permitted to be played
> once. Since we use Alsa, we have to rely on the distribution configuration of
> it though. From the viewpoint of the framework, we don't want to get into
> sample mixing business, hence we recommend people to enable dmix by default in
> their alsa configuration.

Thanks Mickey!!! you are damn right :)
I completely forgot that on debian there is no default /etc/asound.conf!
At this point I think it should be added by the debian installation
script as the freerunner will not ring if some process is using alsa.

Again OT, I just discovered that the triple rtnl/udhcpc signal happens
only on my campus Cisco WDS wifi network.

Regards

    Nicola

RE: Training France Openmoko Android...where?

A comment can be found on the rootdsp.eu course a google group discussion 

 http://groups.google.fr/group/embedded-linux-embarque

>Has anyone been on either the bignerdranch Android course or the RootDSP.eu course? Can they recommend either?

QUOTE Nevel:
>Low level stuff which is a lot easier than doing application level
>programming like on the .

>Low level is easier then high level programming? Have you ever done any low level programming...I dont
think so!!

Message: 9
Date: Mon, 18 May 2009 23:49:00 +0200
From: Nevel Shute <devlinlion at gmail.com>
Subject: Re: Training France Openmoko Android...where?
To: smartphones-userland at linuxtogo.org
Message-ID:
       <8a44c4690905181449i44d6f16dja80770edfe3fd869 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

bignerdranch.com <http://www.bignerdranch.com/classes/android.shtml>is
about programming in the Android enviroenment, high level. Helps with
programming applications for the Android based phone. Sounds interesting and
useful. Where as RootDSP.eu is about embedded programming, drivers and just
uses the Openmoko phone and flashs Android as a prelude/example to the
overall how to embed an OS.
Low level stuff which is a lot easier than doing application level
programming like on the .

[Debian] E: Package libevas-engines has no installation candidate

Hi,

I'm installing Debian on the neo from scratch.

Currently (2009-07-05 11h UT) this fails with

* Zhone GUI: true
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you
have
requested an impossible situation or if you are using the
unstable
distribution that some required packages have not yet been
created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
  zhone: Depends: python-edbus but it is not going to be
installed
         Depends: python-ecore but it is not going to be
installed
         Depends: python-edje but it is not going to be
installed
         Depends: python-evas but it is not going to be
installed
         Depends: libevas-engines (>= 0.9.9.050+svn20090204)
but it is not installable

Re: [Debian] E: Package libevas-engines has no installation candidate

On Sun, Jul 05, 2009 at 11:53:13AM +0200, e.waelde wrote :

> Any ways around this?
> 

My bad, I thought that as some packages still had a dependency on
libevas-engines, it would get removed from experimental even though there's now
a newer version in unstable.
Apparently I was mistaken. I'm going to prepare an upload which uses the newer
evas version. Sorry for the inconvenience.

Regards,
--

-- 
Albin Tonnerre

_______________________________________________
Smartphones-userland mailing list
Smartphones-userland <at> linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland

Re: Deprecating xserver-glamo (was: Recording from headset when pressing headset button

2009/6/24 Luca Capello <luca <at> pca.it>:
> The major problem here is that we need too many extra stuff: a new
> kernel, a new libdrm and then a new xf86-video-glamo.  Moreover, since
> libdrm is already in Debian main, we should coordinate any new package
> upload with its maintainer.

If it gets ready this is all doable. But at the moment that stuff is
purely for user testing if something works or not.

> Finally, is someone actually working on Glamo?  Its life is directly
> linked with GTA02, since, as it was planned for GTA03, the new
> gta02-core community project has removed it.

Regarding working on development, Lars-Peter at least has again done a
few ioctl-related commits. It's been a few weeks since we've heard
from Thomas (AFAIK), but he seemed enthusiastic about experimenting
with KMS & OpenGL.

Whatever the case, it is probable FreeRunner will still be the only
truly Free phone for the next two years or so at least. Gta02-core
might not ever produce an actual hw product, and the other Linux
phones are not as hackable. Currently the glamo operation is not rock
stable, and is loading CPU too much - the major usage improvement for
all of us would be to get KMS into stable state, in which case glamo
can be guaranteed the regular calls it requires for functioning
properly (user-space cannot guarantee this). At the same time KMS
could be, in my very limited understanding, the key to not stalling
CPU on gfx operations by not busy-looping anymore.

Regarding Debian, nothing needs to be done at the moment regarding