On 15/08/08 15:20:53, Benito Torres wrote:
>
> On the cpu-hogging: playing mp3s takes constantly ~30% (with and
> without
> pulseaudio). But mplayer also uses 25%, while in OM2007.2 it was
> around
> 10%. So maybe this is not a mediaplayer-issue but one of the
> sound-subsystem?
In FSO just go int
Michael 'Mickey' Lauer wrote:
> Am Freitag 15 August 2008 09:02:42 schrieb Russell Sears:
>> Michael 'Mickey' Lauer wrote:
>>> Am Donnerstag 14 August 2008 19:08:39 schrieb Russell Sears:
Anyway, [music|gps] + gprs + phone seem to play nice in FSO. (I hacked
up a openmoko-mediaplayer pac
Lovely. Thanks.
Can someone please test and wikify?
Thanks,
Michael
Russell Sears wrote:
> The package I'm using (and dependency packages) is now up at
> http://hedora.ath.cx/moko/
>
> Let me know if you hit any problems.
>
> -Rusty
>
> Russell Sears wrote:
>> There are a bunch of manual ste
On Thu, Aug 14, 2008 at 23:32 (-0700), Russell Sears wrote:
> The package I'm using (and dependency packages) is now up at
> http://hedora.ath.cx/moko/
Thanks!
Most dependencies I already had installed from the °angström-base-feed.
To install your mediaplayer-package I only had to change the
cor
Am Freitag 15 August 2008 09:02:42 schrieb Russell Sears:
> Michael 'Mickey' Lauer wrote:
> > Am Donnerstag 14 August 2008 19:08:39 schrieb Russell Sears:
> >> Anyway, [music|gps] + gprs + phone seem to play nice in FSO. (I hacked
> >> up a openmoko-mediaplayer package.
> >
> > Cool.
> >
> >> Head
Michael 'Mickey' Lauer wrote:
> Am Donnerstag 14 August 2008 19:08:39 schrieb Russell Sears:
>> Anyway, [music|gps] + gprs + phone seem to play nice in FSO. (I hacked
>> up a openmoko-mediaplayer package.
>
> Cool.
>
>> Headphone insertion isn't detected
>> yet, but it does mute/stop the music
The package I'm using (and dependency packages) is now up at
http://hedora.ath.cx/moko/
Let me know if you hit any problems.
-Rusty
Russell Sears wrote:
> There are a bunch of manual steps right now:
>
> - openmoko-mediaplayer is hardcoded to use pulseaudio. Switching to
> alsa is a one-lin
7MB/s should be enough for anyone :)
IMHO when you view the Glamo as just a few cores it becomes a lot cooler.
On 8/15/08, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote:
> On Thu, 14 Aug 2008 20:32:22 +0200 Joachim Steiger <[EMAIL PROTECTED]>
> babbled:
>
>> qrazi wrote:
>> > The test
There are a bunch of manual steps right now:
- openmoko-mediaplayer is hardcoded to use pulseaudio. Switching to
alsa is a one-line change.
- the mediaplayer theme files need to live in the Raleigh directory
not in Moko
- There's some dependency on a openmoko sound system. I don't know
On Thu, Aug 14, 2008 at 10:08 (-0700), Russell Sears wrote:
> Anyway, [music|gps] + gprs + phone seem to play nice in FSO. (I hacked
> up a openmoko-mediaplayer package.
Would you provide that to us? I'd like to use it, too.
Thx,
/Ben
___
Openmoko
Am Donnerstag 14 August 2008 19:08:39 schrieb Russell Sears:
> Anyway, [music|gps] + gprs + phone seem to play nice in FSO. (I hacked
> up a openmoko-mediaplayer package.
Cool.
> Headphone insertion isn't detected
> yet, but it does mute/stop the music when you pick up the phone).
Please add
Benito wrote:
> On Wed, Aug 13, 2008 at 14:06 (-0700), Russell Sears wrote:
>>> It works immediatly with FSO and I could phone while GPRS is on.
>> Really?!? How? Is there a GUI somewhere, or did you edit the PPP
>> scripts to enter your provider settings?
>
> See http://wiki.openmoko.org/wiki/
On Wed, Aug 13, 2008 at 14:06 (-0700), Russell Sears wrote:
> > It works immediatly with FSO and I could phone while GPRS is on.
>
> Really?!? How? Is there a GUI somewhere, or did you edit the PPP
> scripts to enter your provider settings?
See http://wiki.openmoko.org/wiki/GPRS_FSO
The scrip
On Thu, 14 Aug 2008 00:29:44 +0100 tim <[EMAIL PROTECTED]> babbled:
> An idea I came across recently that seems like a good idea is a hybrid
> approach, where the devs passively observe /all/ traffic from users
> (irc, mailing lists, support mailboxes, bug trackers etc), and can pick
> out bits
Bear in mind reading this that I'm aware I know nothing of your internal
workings, and wouldn't presume to know better. I just hope to contribute
something from my experiences, and will take no offence if ignored.
Holger Freyther wrote:
> ---
> Now we have bugreports like the SIM PIN Dialog or t
Holger Freyther wrote:
yeah, this is work in progress. Stuff like two bug trackers, controlling some
more fields.. and various other things float through my head and I have to
organize this first. Other entities fix that by shielding developers and
putting 1st line support there acting as a mul
Mike Baroukh wrote:
>> Trust me, to avoid it,
>> for a while I really considered shipping a console-image for the framework
>> image, forcing people to ssh into to start getting familiar with the dbus
>> services...
Why try to avoid it? Isn't it the shortest path to a working phone?
If the fr
I don't know if I agree with the suggestions of this user, but since we're
brainstorming, I have one thought :)
Discrete components should be managed as separate packages with separate
project pages and information and repositories and bug trackers and such.
There's no reason for everything to
On Wednesday 13 August 2008 12:34:06 Norbert Hartl wrote:
> Don't forget the problem reports which are a valuable source of feedback
> for those developers. So the bugtracker is also for reporting bugs and
> enhancement wishes.
It is. In the SIM PIN Dialog bug the log was really helpful to identi
On Wed, 2008-08-13 at 14:09 +0200, Olivier Berger wrote:
> Holger Freyther <[EMAIL PROTECTED]> writes:
>
> > On Wednesday 13 August 2008 00:05:14 Jeffery Davis wrote:
> >
> >> 2. Better communication between the development community and the end
> >> user community. I have yet to see anyone say t
>>
>> silly me believing not understanding irony was an entirely german
>> disease
>> ...
>
> He said the intention was basically 'fork early, fork often'. I
> simply
> asked 'Why?' He didn't explain the reasoning.
>
There is no reasoning. Its a destructive policy, plain and simple.
;
--
J
> Explain to me the reasoning behind forking the software at this point.
> What does it accomplish, besides paying lip service
> to choice? I'm thinking of the Bible story of Solomon and the two
> mothers here. What good is half a baby? Wait until there's something
> /worth/ forking.
> Can anyon
> silly me believing not understanding irony was an entirely german disease
> ...
He said the intention was basically 'fork early, fork often'. I simply
asked 'Why?' He didn't explain the reasoning.
___
Openmoko community mailing list
community@lis
>> aaah - but this is what om wants! as per will's words (product
>> management for
>> OM): "Everyone should fork. Everyone should create their own
>> distribution"
>> ...
>> this is om's intention and desire.
>>
>
> Explain to me the reasoning behind forking the software at this point.
silly
I mistakenly sent this response via private email to Carsten when I
meant to post it to the list.
Original Message
Subject:Re: What could be done to improve the OM development process?
Date: Tue, 12 Aug 2008 20:58:41 -0400
From: Jeffery Davis <[EMAIL PROTECTED]&
Holger Freyther <[EMAIL PROTECTED]> writes:
> On Wednesday 13 August 2008 00:05:14 Jeffery Davis wrote:
>
>> 2. Better communication between the development community and the end
>> user community. I have yet to see anyone say they're pleased
>> as punch with the keyboard. When almost everyone i
On Wednesday 13 August 2008 12:34:06 Norbert Hartl wrote:
> On Wed, 2008-08-13 at 11:02 +0200, Holger Freyther wrote:
> > On Wednesday 13 August 2008 00:05:14 Jeffery Davis wrote:
> > > 2. Better communication between the development community and the end
> > > user community. I have yet to see an
> On Wednesday 13 August 2008 00:05:14 Jeffery Davis wrote:
>
> > 2. Better communication between the development community and the end
> > user community. I have yet to see anyone say they're pleased
> > as punch with the keyboard. When almost everyone is unhappy, closing
> > bugs as 'working a
On Wed, 2008-08-13 at 11:02 +0200, Holger Freyther wrote:
> On Wednesday 13 August 2008 00:05:14 Jeffery Davis wrote:
>
> > 2. Better communication between the development community and the end
> > user community. I have yet to see anyone say they're pleased
> > as punch with the keyboard. When
On Wednesday 13 August 2008 00:05:14 Jeffery Davis wrote:
> 2. Better communication between the development community and the end
> user community. I have yet to see anyone say they're pleased
> as punch with the keyboard. When almost everyone is unhappy, closing
> bugs as 'working as intended'
>
> Trust me, to avoid it,
> for a while I really considered shipping a console-image for the framework
> image, forcing people to ssh into to start getting familiar with the dbus
> services...
hum ...
personnaly, I use it.
I couldn't get my GPRS work on ASU.
It works immediatly with FSO and I c
Am Mittwoch 13 August 2008 09:24:46 schrieb Olivier Migeot:
> On Wed, Aug 13, 2008 at 12:05 AM, Jeffery Davis
>
> <[EMAIL PROTECTED]> wrote:
> > 1. Instead of working on multiple concurrent software distributions, why
> > not try to rally everyone under one banner for a while?
>
> Just my cheap com
On Wed, Aug 13, 2008 at 12:05 AM, Jeffery Davis
<[EMAIL PROTECTED]> wrote:
> 1. Instead of working on multiple concurrent software distributions, why
> not try to rally everyone under one banner for a while?
Just my cheap comment on this : I feel less and less like there's
multiple concurrent sof
On Tue, 12 Aug 2008 18:05:14 -0400 Jeffery Davis <[EMAIL PROTECTED]>
babbled:
> Two thoughts...
>
> 1. Instead of working on multiple concurrent software distributions, why
> not try to rally everyone under one banner for a while?
> People are going to work on what they want to work on to some d
Two thoughts...
1. Instead of working on multiple concurrent software distributions, why
not try to rally everyone under one banner for a while?
People are going to work on what they want to work on to some degree,
but an attempt should be made at least. Choice is great
and all, but in the begi
35 matches
Mail list logo