| |
| |
| |
|
Page: 1 2 3
Comments:
<0> From grepping for it, guess not.
<1> koen: http://www.linuxdevices.com/news/NS9048137234.html
<2> hrw: http://dominion.kabel.utwente.nl/koen/cms/arm-eabi-fame :)
<1> I know your post
<2> hrw: pretty nice PR for OE and angstrom
<0> koen: right in time for fosdem
<1> koen: too bad that none of them was mentioned at end (Avability section)
<1> koen: write good About page on Angstrom homepage
<1> koen: then write base version, send it to angstrom-devel
<1> koen: and linuxdevices does not even mention angstrom
<3> Can someone tell me what GPE uses for sound?
<3> I know OPIE uses QSS, but what can be used in X?
<2> alsa, oss, esound, pulse-audio, arts, jack, etc
<3> Ah, I forgot to say that ALSA doesn't work
<3> I need something that uses /dev/dsp directly
<3> oss doesn't exist
<3> In OE
<3> Will esound work for applications that support esd?
<2> esound == esd
<3> aha
<3> I know
<2> if you go that route, I'd recommend using pulseaudio
<3> I'll look into it
<3> Is it compliant with ALSA or OSS?
<2> both
<3> Great, thank you very much
<3> You've been a great help
<4> re
<4> hi everyone
<2> Jin^eLD: wb
<4> thx
<1> rfc sent
<5> koen org.oe.dev * r26445... / (10 files in 9 dirs): lots of files: esound-gpe -> esound
<0> hi Jin^eLD
<4> hey likewise
<0> hrw: did you build for x86_64 sometime?
<5> koen org.oe.dev * red090... / (1 conf/distro/angstrom-2007.1.conf): angstrom: add preferred provider for esound
<5> koen org.oe.dev * recc22d6... / (1 packages/pulseaudio/pulseaudio_0.9.5.bb):
<5> pulseaudio: provide esound
<5> * should be change this to virtual/esound?
<1> likewise: no
<0> hrw: ah, I thought you did.
<1> likewise: do we have x86_64 target? I only use it as host
<6> ok....time to rewrite this embeddix crap
<0> JustinP: what stuff are you looking at?
<7> hi
<0> hrw: no, seems we do not support x86_64 currently as the target, and it breaks awfully at it also.
<1> likewise: I build {opie,gpe,bootstrap}-image from .oz354x
<1> likewise: gpe/bootstrap/xfce image from .dev
<1> likewise: all on amd64 in 64bit
<0> hrw: ok, tnx
<6> likewise: CE-RHx module
<1> cu
<6> likewise: rewriting their crazy state machine
<8> hi Jin^eLD - i took mediatomb out for a spin yesterday.
<4> :)
<4> on what hardware?
<4> ...did it work? :>
<8> iomega storcenter.
<8> (running the openprotium image)
<9> JustinP: hi
<4> HopsNBarley: never heard of it, gotta look on the net; what CPU is it? ...and most importantly - how did it work out? :)
<8> i had to adjust the build for PPC, but it did build and run okay.
<8> it's a freescale 8241 at 200Mhz.
<4> cool, something new - meaning - I never tested it on such hardware
<4> what did you have to adjust?
<4> on mediatomb side?
<8> loading my test library of around 1000 sounds it would segfault after about 10 or 20 minutes of loading things into sqlite.
<4> uhh...
<8> it was mainly the spidermonkey build that needed work.
<8> sounds ==songs, sorry.
<4> which version did you use? did your version already have the atomic code for refcounting?
<8> i just used the existing bitbake, which is 0.8+0,9pre-1+svn...
<8> i looked at your cvs tags, and 0.8.1 is the last tag many moons ago.
<4> yes, you should use the latest SVN code
<4> forget about 0.8.1, it is really outdated
<8> i think that's what the BB file does, it did do a SVN get.
<4> oh ok
<4> well, in this case its bad news for us :> the atomic code should be in there, that means the segfault comes from.. somewhere else
<8> i was wondering if it was a bleeding edge problem, and was looking for an older tag...
<4> there are no tags since 0.8.1...
<8> what can I do to help you find the fault? build with -g ? make sure it cores?
<4> yes, coredump would be very helpful, also build with --enable-tombdebug
<8> got it.
<8> i did notice it uses a lot of memory >100M.
<4> it will print out lots of stuff then that might give us an idea what the server was doing when it fsck'd up
<6> RP: hi
<4> yeees... well. we still need to look into that... the truth is - it was originally written for a PC environment
<6> RP: i'm working on rewriting the main loic of the driver right now, from scratch
<4> everything C++ object oriented, reference counting - that eats up quite some memory
<9> JustinP: Probably easiest :)
<6> RP: I have it sending switch events for remote plugin and removal in the current code, but it's not perfect
<4> HopsNBarley: later on we figured that it compiles and runs on embedded devices as well, but by that time the whole architecture was setup and it is not easy to get memory consumption under control
<8> i understand.
<6> RP: I was wondering if perhaps another one of those GPIOs might have more info on insertion...or if you know where the Sharp code was doing the insertion
<8> i'm rebuilding now with --enable-tombdebug.
<4> HopsNBarley: would be cool if you could compile with -g, both CFLAGS and CXXFLAGS -O0 and do a backtrace on the core
<4> thanks
<8> i'll check in the PPC patches for spidermonkey at some point.
<6> RP: as it is now, there are 2 different headphone insert/remove switches....
<9> JustinP: The only pieces of info we have are the HP detect GPIO and the AK data line to the adc. I know for a fact we don't have any others
<8> i was using 1.6, could that be aproblem?
<4> HopsNBarley: did it crash in spidermonkey? does it crash if you compile and run without spidermonkey?
<4> actually the spidermonkey version should not be the problem...
<8> i have no idea yet where it crashed.
<9> JustinP: There are not two switches. There is one switch and the other is the data line from the report which connects to the ADC
<6> RP: it *looks* like the 2.4 kernel was using the remote logic to deal with inert/remove
<9> JustinP: If the remote doesn't trigger the usual switch, it would have to
<6> RP: what I meant was that I've implemented the same switch in the remote driver based on the keys received so now there are 2 user-land switches
<6> RP: I suppose we can figure that out once I've rewritten this thing
<9> JustinP: Yes, once you work out what the hardware does/doesn't do we can work it out
<6> RP: thanks, I just wanted to know if there was a possibility of more insertion data. That switch from the keyboard works great....for normal headphones..:-| I wish they'd put this thing together right.
<9> JustinP: You have all the data I'm afraid
<6> RP: ok. I'll let you know when I have something worth looking at.
<7> hi there, is the kernel sources the various distros are using just vanilla sources + patchsets?
<7> does anybody know that?
<7> oh iforgot that i mean the 2.6ers
<7> not the 2.4ers
<9> doch: Some machines use plain kernels, some are patched
<7> allright thancks
<6> doch: RP has been doing a great job supporting hardware and pushing his patches upstream :-)
<7> meaning they were put into the vanilla-tree?
<9> doch: Lots of changes have been, yes
<8> Jin^eLD, still around?
<4> yes, sure
<8> oh, great. it doesn't come with a default conf or init file... should i just run it as root from the command line as I've been doing?
<4> yes, please try to reproduce
<4> basically it creates a config file itself, in ~/.mediatomb/config.xml
<8> it's rebuilt and ready to go. want to get a useful test for you.
<4> thanks!
<10> RP: congrates for the new collegue. cu tomorrow
<7> RP: wow, thats great
<9> greentux|bed: thanks, cu!
<8> one possible problem - i'm running another process which is ssh'ing over some more music into the tree. will files being created right under it cause problems?
<4> HopsNBarley: good question... we do various things, like fstat for example, and then we feed the files to the metadata handlers, like id3lib or taglib or whatever
<4> so if one of those libs tries to parse the file while data is being written... who knows
<4> would be really interesting to see the backtrace
<8> ok, i'm importing the diretory now...
<4> roger that
<8> Jin^eLD, okay, it's going wild doing addObjects() and so forth.
<4> uaah
<4> aah, ok
<4> so just adding hehe
<8> it took a while to crash yesterday, so i'll be back...
<4> I thought "going wild" was coredumping or something like that :>
<8> no, sorry.
<4> HopsNBarley: it is likely that I oversee the messages in #oe if the guys start talking
<4> could you please give me a signal in #mediatomb?
<8> oh, sure, hold on....
<4> thanks
Return to
#oe
or
Go to some related
logs:
#linux
#perl
NVmakedevices.sh
explore2fs fc5
fusermount: fuse device not found, try 'modprobe fuse' first
osdev rtl
AMBROSH
unfiltered SQL
get_client_info perl
<0>Kernel panic - not syncing: Attempted to kill init! + ubuntu
|
|