On Wednesday 10 March 2010, Laurent GUERBY wrote:
> On Wed, 2010-03-10 at 21:54 +0200, Siarhei Siamashka wrote:
> > I wonder why the compiler does not use real NEON instructions with
> > -ffast-math option, it should be quite useful even for scalar code.
> >
> > some
fast-math already assumes no support for NaNs. Even if
there are other nice IEEE754 things preventing NEON from being used
with -ffast-math, an appropriate new option relaxing this requirement
makes sense to be invented.
--
Best regards,
Siarhei Siamashka
On Wednesday 10 March 2010, Laurent Desnogues wrote:
> On Wed, Mar 10, 2010 at 8:54 PM, Siarhei Siamashka
> wrote:
> [...]
>
> > I wonder why the compiler does not use real NEON instructions with
> > -ffast-math option, it should be quite useful even for scalar code
[r0]
for:
*float_ptr = *float_ptr + *float_ptr;
At least NEON is pipelined and should be a lot faster on more complex code
examples where it can actually benefit from pipelining. On x86, SSE2 is used
quite nicely for floating point math.
--
Best regards,
Siarhei Siamashka
___
s change the overall picture
quite dramatically. It makes almost no sense benchmarking -O0 code, because in
this case all the local variables are kept in memory and are read/written
before/after each operation. It's substantially different from normal code.
--
Best regards,
Siarhei S
ship to you. Maybe they don't have time
or have other reasons not to work on the project actively and will be
glad to know that somebody wants to take it over.
--
Best regards
Siarhei Siamashka
___
maemo-developers mailing list
maemo-developers
to nokians reading, PLEASE make sure this works and also confirm that
> XV rotates correctly as well ;)*
>
> Gary Birkett (lcuk in #maemo)
By the way, have you reported this XV rotation problem to the authors of the
unofficial rotation patch? What d
On Tuesday 13 January 2009, Frantisek Dufka wrote:
> Siarhei Siamashka wrote:
> > XV should make a perfect backend for SDL, because it maps fine on SDL
> > API (SDL_SetVideoMode/SDL_Flip/...). In general, XV is a good backend
> > for anything that uses double-buffer
e can handle it well, please describe what exactly you want to do.
I'll try to advice something.
--
Best regards,
Siarhei Siamashka
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
On Tue, Jan 13, 2009 at 12:23 PM, Felipe Contreras
wrote:
> On Tue, Jan 13, 2009 at 12:05 PM, Igor Stoppa wrote:
>> Hi,
>> On Tue, 2009-01-13 at 18:06 +0800, ext Huang Gao (Gmail) wrote:
>>> Hi, Igor Stoppa:
>>> Thank you for your reply!
>>> So can I understand that this hardware FB i
On Tue, Jan 13, 2009 at 10:56 AM, Frantisek Dufka wrote:
> BTW, there is kernel ioctl to set automatic refresh and the refresh rate
> can be tweaked in kernel source but the results are suboptimal. Maybe at
> least for Nokia 770 it would be possible to use tearsync flag for such
> automatic update
snail ;)
Especially when excessively complex frameworks and layers are used, chances
of having something implemented inefficiently in between get a bit higher.
--
Best regards,
Siarhei Siamashka
___
maemo-developers mailing list
maemo-developers@maemo.org
http
On Friday 26 September 2008, Robert Schuster wrote:
> Hi,
>
> Siarhei Siamashka schrieb:
> > Recently I have been trying to make it running and seems like we have a
> > very good chance to have it working nicely. It is also interesting, that
> > the linux-omap guys
l by changing
.tcf file and enabling different kernel features. Documentation which explains
its syntax is available in free DSP toolchain.
So DSP programming for 770 and other OMAP1 based devices should be perfectly
fine. But I can't say the same for N8x0 at the moment, because free DSP
tool
On Friday 26 September 2008, Felipe Contreras wrote:
> On Fri, Sep 26, 2008 at 12:06 AM, Siarhei Siamashka
>
> <[EMAIL PROTECTED]> wrote:
> > On Thursday 25 September 2008, Felipe Contreras wrote:
> >> On Thu, Sep 25, 2008 at 10:07 PM, Siarhei Siamashka
> >
&g
On Thursday 25 September 2008, Felipe Contreras wrote:
> On Thu, Sep 25, 2008 at 10:07 PM, Siarhei Siamashka
[...]
> > Now regarding why we may want it. Once if we get a good, low latency,
> > fully functional and reliable ALSA sound driver running on ARM, it gives
> > m
ipermail/maemo-developers/2006-June/022231.html
2. http://focus.ti.com/docs/prod/folders/print/tlv320aic23b.html
3. http://thread.gmane.org/gmane.linux.ports.arm.omap/11700/focus=11709
4.
https://www-a.ti.com/downloads/sds_support/targetcontent/LinuxDspTools/index.html
5. http://www.gossamer-threads
On Thu, Jul 10, 2008 at 6:57 PM, Simon Pickering
<[EMAIL PROTECTED]> wrote:
> No, I understood, I was just mentioning that there appear to be two
> heaps to chose from - presumably one is used by the DSP tasks (malloc is
> probably #defined as one of the CSL MEM* fns in the DSP Gateway task
> funct
On Thu, Jul 10, 2008 at 5:09 PM, Simon Pickering
<[EMAIL PROTECTED]> wrote:
>> > I looked at this yesterday evening (thanks to derf, crashanddie, and
> others
>> > for answering my C questions), trying to move some parts of the priv
>> > structure to SARAM (sorry for the SRAM typo above). Unfortuna
On Thu, Jul 10, 2008 at 2:06 PM, Simon Pickering
<[EMAIL PROTECTED]> wrote:
>> The change which has allowed it to encode an entire song rather than just
> a
>> few seconds was to move the input and output buffers from SDRAM (OMAP main
>> memory) to SRAM (DSP fast single access memory). There are pr
ia 770 version) collected together by Rodrigo Vivi and posted
here: https://garage.maemo.org/pipermail/cx3110x-devel/2008-April/38.html
--
Best regards,
Siarhei Siamashka
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
On 3 March 2008, Gustavo Sverzut Barbieri wrote:
> On Sun, Mar 2, 2008 at 2:17 PM, Vinod Hegde <[EMAIL PROTECTED]> wrote:
> > Hi Everyone,
> >
> > How do I access the hardware performance counters available in OMAP2420.
> > what are the header files that contain the implementation.
> > I tried lots
On 22 February 2008, Frantisek Dufka wrote:
> Kalle Valo wrote:
> >> Also CPU usage is very high because of busyloop when waiting till
> >> DMA transfer is done. Tasklet, which executes the code can't be
> >> easily preempted, as far as I understand kernel documentation. Maybe
> >> it is possible t
On Feb 14, 2008 8:43 AM, Kalle Valo <[EMAIL PROTECTED]> wrote:
[...]
> > other users reported it too as Luca Olivetti pointed out. and it
> > seems like the problem and fix is described here:
> >
> > http://internettablettalk.com/forums/showpost.php?p=134914&postcount=15
> >
> > at least for the 77
On Feb 18, 2008 1:28 PM, Tapani Pälli <[EMAIL PROTECTED]> wrote:
> > Could you please verify and confirm this information? Framebuffer
> > driver from OS2007 supported tearsync (via OMAPFB_FORMAT_FLAG_TEARSYNC
> > flag as Frantisek mentioned), and it was used at least for video.
> > Well, I have no
On Feb 18, 2008 9:39 AM, Tapani Pälli <[EMAIL PROTECTED]> wrote:
> > When using the supplied SDL library for doing timer-based frame
> > rendering, there seems to be
> > - heavy tearing
>
> Tearing unfortunately happens because there is no vsync available for
> framebuffer driver to use.
Could you
On Feb 17, 2008 9:56 PM, Tobias Oberstein <[EMAIL PROTECTED]> wrote:
[...]
> I've read a lot of bits on the web 'bout mplayer, vsync, omapfb etc.
> and tried to assemble a minimal example of using direct framebuffer
> access for gfx output.
>
> Q: I can't get the tearing away (only fixed at certa
On 31 December 2007, Frantisek Dufka wrote:
> Igor Stoppa wrote:
> > Having the audio path open, but no dsp tack loaded (arm audio) sets the
> > clock to 400MHz.
>
> Interesting, so, umm, there is way to play audio from ARM side directly?
> What I tried is to play BBC radio in home screen applet wh
On 30 December 2007, Frantisek Dufka wrote:
> Krischan Keitsch wrote:
> > I was wondering if the device really needs to run at 300MHz (220MHz dsp)
> > for mp3 playback? Is the max dsp power needed for such a task? Or would
> > 220MHz (177MHz dsp) or 165MHz (85MHz dsp) be sufficient? Would a lower
>
On 9 November 2007, Alex DAMIAN wrote:
> the modified cx3110x driver works ok. I think it's a bit weird that my
> WRT router would assign different IP addresses depending on the driver
> loaded, but it's not an inconvenience after all.
>
> However I run into a bit of trouble trying to modify the in
On 14 September 2007, Charles 'Buck' Krasic wrote:
> I did some experimentation a while back with DSP <-> ARM communication
> via mmap'ed memory, in my case I was working on using the DSP for rgb
> to yuv conversion. Another big gotcha to look out for is 64k
> boundaries. The DSP (at least in the 7
On 30 August 2007, Jesse Guardiani wrote:
> Koen Kooi wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Jesse Guardiani schreef:
> >>> And the related question is: given an existing program that sends
> >>> stuff out to ALSA and doesn't use gstreamer, how difficult is it
On Wednesday 18 July 2007 13:01, Simon Pickering wrote:
> Does anyone know whether there are there any good docs/books on ARM asm
> programming, telling people these sort of things? This is an interesting
> (and hopefully useful) learning experience, but can be really frustrating
> when I know wha
On Friday 25 May 2007 11:42, Juuso Räsänen wrote:
> I have been trying to compile MPlayer myself under Maemo 3.1.
> I've used patches from:
> https://garage.maemo.org/frs/?group_id=54
>
> However, commands...
>
> [sbox-SDK_ARMEL: ~/MPlayer-1.0rc1-maemo.16] > ./configure
> [sbox-SDK_ARMEL: ~/MPlaye
On Thursday 03 May 2007 12:58, Eero Tamminen wrote:
> ext Siarhei Siamashka wrote:
> > What problem with using framebuffer directly? Everything should be
> > fine, you can get notifications from xserver when your window becomes
> > obscured, so you can stop drawing. I sugge
On Friday 04 May 2007 10:49, Daniel Stone wrote:
> On Thu, May 03, 2007 at 11:10:32PM +0300, ext Siarhei Siamashka wrote:
> > Well, found what's the matter and added explanation at bugzilla:
> > https://maemo.org/bugzilla/show_bug.cgi?id=1281
> >
> > The workaroun
On Monday 30 April 2007 14:27, Siarhei Siamashka wrote:
> I also tried to use YUV420 on Nokia 770, but it did not work well.
> According to Epson, this format should be supported by hardware. Also there
> is a constant OMAPFB_COLOR_YUV420 defined in omapfb.h in Nokia 770 kernel
>
On Thursday 03 May 2007 10:21, Frantisek Dufka wrote:
> Siarhei Siamashka wrote:
> > If decoding time for
> > each frame will never exceed 28-29ms (which is a tough limitation, cpu
> > usage is not uniform), video playback without dropping any frames will be
> >
On Thursday 03 May 2007 08:48, Siarhei Siamashka wrote:
> The only thing which is unclear here is that Hailstorm does not need to
> downscale video in this situation. The bug can be reproduced with 512x288
> video which just needs upscaling to 800x450. Also even standard
> Nokia_N8
On 5/3/07, Eero Tamminen <[EMAIL PROTECTED]> wrote:
[...]
Same problem as using framebuffer directly. How user switches
to another application? How to invoke power menu properly etc.
What problem with using framebuffer directly? Everything should be
fine, you can get notifications from xse
On Wednesday 02 May 2007 12:39, Daniel Stone wrote:
> On Wed, May 02, 2007 at 09:16:01AM +0300, ext Siarhei Siamashka wrote:
> > On Tuesday 01 May 2007 20:49, Siarhei Siamashka wrote:
> > > Results with unpatched xserver and some more explanations can be found
> > > in
On Wednesday 02 May 2007 12:47, Daniel Stone wrote:
> > > X11 error: BadValue (integer parameter out of range for operation)
> > > MPlayer interrupted by signal 6 in module: flip_page while gstreamer
> > > did play them just fine. Also the Nokia_N800.avi and NokiaN93.avi died
> > > in the same way
On Wednesday 02 May 2007 12:54, Daniel Stone wrote:
> > The 'framebuffer' is just the ordinary system memory, converting color
> > format and copying data to framebuffer will be done with the same
> > performance as simulated in this test. RFBI performance is only critical
> > for asynchronous DMA
On Wednesday 02 May 2007 23:01, Arnim Sauerbier wrote:
> If the memcpy on 770 is something like 190MB/s, pushing 800x480 at 30fps
> would use only 12 percent of that bandwidth
I'm sorry, I was the source of this misleading information, I forgot that
you are a Nokia 770 user and mentioned some num
On Wednesday 02 May 2007 18:48, Eero Tamminen wrote:
> On x86 I prefer valgrind/cachegrind/callgrind/kcachegrind as
> that way one can browse the source code interactively with
> the profiling information. Getting to know how the source
> really works is sometimes more useful than knowing the exac
On Wednesday 02 May 2007 20:40, Daniel Stone wrote:
> > For the use case which is being described here - namely always full
> > screen applications which need exclusive access to the display at a
> > lower resolution Why not do something like switch to another VT and do
> > it directly on the frame
On Monday 30 April 2007 12:26, Frantisek Dufka wrote:
> Daniel Stone wrote:
> > Specifying that pixels must be exactly _doubled_ is a
> > hack around both the performance issues and a lack of resolution
> > independence. Apparently an important one, if you happen to like SDL
> > games, but a hack
On Tuesday 01 May 2007 20:49, Siarhei Siamashka wrote:
Looks like I have to reply to myself.
> On Tuesday 01 May 2007 17:49, Kalle Vahlman wrote:
> > Applied and build without problems for me.
>
> Thanks a lot for building the package and putting it for download,
> everythin
On Tuesday 01 May 2007 17:49, Kalle Vahlman wrote:
> > OK, here is this untested a patch for xserver to add ARMv6 optimized
> > YUV420 color format conversion. Theoretically it should compile
> > (I did not try to build xserver myself though) and work. If it refuses to
> > compile, fixing the patch
On Tuesday 01 May 2007 13:36, Kalle Vahlman wrote:
> 2007/5/1, Siarhei Siamashka <[EMAIL PROTECTED]>:
> > OK, thanks. It may take some time though. I'm still using old scratchbox
> > with mistral SDK here (did not have enough free time to upgrade yet).
> > Until
On Monday 30 April 2007 17:49, Daniel Stone wrote:
> > ARMv6 optimized YV12->YUV420 convertor is about 2.5x faster
> > than current code used in N800 xserver. So it should provide a nice
> > improvement for video :)
>
> Indeed. Unfortunately this is slightly misleading in that it only shows
> the
On Tuesday 24 April 2007 10:56, you wrote:
> > By the way, do you have any plans for upgrading toolchain? Either I'm
> > extremely unlucky, or current toolchain is really very buggy.
>
> You can see the known issues from the GCC bugzilla.
> There are a few bugs in C++ support which have been fixed
On Friday 27 April 2007 04:43, Daniel Stone wrote:
> > I'll make a really optimized version of YV12 -> YUV420 convertor on this
> > weekend (removing branch is good, but I feel that it can be improved
> > more) and will try to use it on Nokia 770, any extra video performance
> > improvement will b
On Tuesday 24 April 2007 12:36, Daniel Stone wrote:
> > My main performance concern is exactly about this
> > 'omapCopyPlanarDataYUV420' function. My experience from Nokia 770 video
> > output code optimization shows that optimization effect can be really
> > huge (it was 1.5x improvement on Nokia
On Friday 20 April 2007 10:39, you wrote:
> The primary conversion we do isn't planar -> packed (this is a fallback
> for when the video is obscured), but from planar to another custom
> planar format. It would be good to get ARM assembly for the fallback
> path, but most of the problem when usin
On Monday 23 April 2007 16:49, Guillem Jover wrote:
> > You are right. gcc has function
> > void __clear_cache (char *BEG, char *END)
> > which should be more portable.
>
> It should, but it still has the problem of emitting an OABI syscall
> due to our old gcc.
>
> You could use syscall(2) and __
On Friday 20 April 2007 19:04, you wrote:
> > I have seen your code in xserver which does the same job for downscaling,
> > but in nonoptimized C and with much higher impact on quality. Using JIT
> > scaler there can improve both image quality and performance a lot. The
> > only my concern is abou
On Monday 19 March 2007 22:34, you wrote:
> Again, if there are any particular questions I can answer, don't be
> subtle: ask me straight up. If I can answer them (some things I can't
> necessarily say, some things I don't necessarily know), I will.
Thanks, here we go and sorry for a long dela
On Tuesday 20 March 2007 15:03, Klaus Rotter wrote:
> > On Tue, Mar 20, 2007 at 09:31:00AM +0100, ext Klaus Rotter wrote:
> >> The memory bandwidth to the N800 LCD framebuffer is 3 times slower that
> >> the bandwidth in the N770? Is it really _that_ big?
> >
> > Siarhei's calculations were correc
On Wednesday 21 March 2007 09:58, Sampath Goud wrote:
> I want to know if there is frame buffer support in N800.
> I have written a simple application (drawing a pixel) on frame buffer and
> tried to execute it on N800 in root mode.
> But it prompts the message "permission denied".
> Please let me
Hello All,
I did some tests with the framebuffer when trying to find a way to reduce
tearing effect in MPlayer. Here are the results.
I did a mistake when I assumed that screen updates are synchronous for video
planes. They are actually asynchronous just like with Nokia 770, but just a
lot slower
On Saturday 10 March 2007 01:57, Daniel Stone wrote:
> On Fri, Mar 09, 2007 at 10:34:52PM +0200, ext Siarhei Siamashka wrote:
> > On Friday 09 March 2007 12:20, Daniel Stone wrote:
> > > Not really. The next firmware release has gone to great lengths to
> > > improve
On Friday 09 March 2007 12:20, Daniel Stone wrote:
> On Fri, Mar 09, 2007 at 09:45:03AM +0100, ext Hanno Zulla wrote:
> > > Right now, the biggest bottleneck in video decoding is RFBI bandwidth
> > > (i.e. the bus between OMAP and the LCD controller we use), being too
> > > slow to push more than
Hello,
It would be probably a good idea to discuss different possibilities for
improving multimedia support on 770/N800.
Now we have a fast JIT scaler that runs on ARM core, it solves all the
video resolution related performance problems. I'm going to work on
improving quality, performance and
On Thursday 18 January 2007 13:46, Gustavo Sverzut Barbieri wrote:
> > By the way, free software is really poorly optimized for ARM right now.
> > For example, SDL is not optimized for ARM, xserver is probably not
> > optimized as well, a lot of performance critical parts of code in various
> > so
On Wednesday 10 January 2007 01:51, Charles 'Buck' Krasic wrote:
> Siarhei Siamashka wrote:
> > Actually I have been thinking about trying to implement Xvideo
> > support on 770 for some time already. Now as N800 has Xvideo
> > support, it would be nice to ha
On Tuesday 16 January 2007 12:08, Zeeshan Ali wrote:
> > Now, the recently announced Nokia N800 is different from the 770 in
> > various ways that are interesting for Cairo performance. I've got my
> > eye on the ARMv6 SIMD instructions and the PowerVR MBX accelerator.
>
>Yeah! me too. The com
On Sunday 14 January 2007 20:11, Frantisek Dufka wrote:
> Marius Gedminas wrote:
> > On Sun, Jan 14, 2007 at 07:53:06PM +0200, Marius Gedminas wrote:
> >> On Sun, Jan 14, 2007 at 12:11:37AM +0200, Siarhei Siamashka wrote:
> >>> Also Nokia 770 runs not at 220MHz
On Saturday 13 January 2007 21:00, Kalle Vahlman wrote:
> We have all sorts of funny hardware at the office, so I thought I'd
> make a quick run of cairo-perf with the Cairo 1.3.10 snapshot and see
> how they relate to each other.
>
> There's some funny things I encountered in the results, and I h
Hello All,
After reading quite a number of applications posted and in order to add some
diversity here, I decided to actually post a *recommendation* here :)
I hope that Mans Rullgard can be considered for inclusion into the list of
the developers eligible for getting discount code. He is a maint
On Tuesday 09 January 2007 20:59, Charles 'Buck' Krasic wrote:
> Any chance the Xvideo support in the Bora 3.0 will turn up in a 770 OS?
I asked the same question on #maemo irc channel and daniels explained that
video scaling is done by gpu on N800, so probably the same code can't be
reused on 7
On Monday 08 January 2007 09:02, Komal Shah wrote:
> Ok. Let's fun begin.
>
> It looks like OMAP2420 only. As per the development track on
> linux.omap.com kernel mailing list the product may _NOT_ be using the
> IVA1.0 processor. Basically OMAP2420 from the multimedia point of view
> is a MPEG4 d
On Tuesday 12 December 2006 01:57, you wrote:
> My original goal of posting the previous message was an attempt to find a
> volunteer who would like to try developing such a frontend.
>
> I don't have that much time to devote to mplayer development myself. Up
> until this moment I even could not c
On Monday 11 December 2006 11:26, Frantisek Dufka wrote:
> Yes, the result would look like video overlay works in windows or linux
> on PC - overlay draws over different windows when it shouldn't :-) We
> can live with that.
I thought it is actually not a problem but quite a good thing :-) Surely
Hello All,
I have just uploaded a new build of mplayer (mplayer_1.0rc1-maemo.3) to
garage, which implements some experimental and not yet clean video output
method using hardware YUV colorspace and direct access to framebuffer. It's
not quite usable as framebuffer access is not allowed when runnin
Hello All,
Here is an old link with some benchmarks and initial information:
http://maemo.org/pipermail/maemo-developers/2006-March/003269.html
Now for more completeness, memcpy equivalent is also available and
the functions exist in two flavours (either gcc inline macros, or just
assembly code)
On Thursday 23 November 2006 21:02, you wrote:
> On Monday 13 November 2006 22:08, Andrew Barr wrote:
> > What are my options for Windows Media Audio streams on the 770? Most
> > Internet radio streams (I mean simulcasts of real broadcasts in this
> > sense) are offered in (at least) this format,
On Saturday 25 November 2006 19:05, George Farris wrote:
> On Sat, 2006-25-11 at 18:34 +0200, Stefan Kost wrote:
> > Hi George,
> >
> > To make it a bit more clear: If there are plans, we would not be allowed
> > to talk about it :(. So you'll have to wait. But be assured it if is
> > technically
On Thursday 23 November 2006 22:19, Charles 'Buck' Krasic wrote:
> No, my dsp work was actually video related.I did reuse Siarhei
> Siamashka's mplayer code to decode/output mp3 directly, but that
> obviously doesn't help with speex.
Just a disclaimer before anybody starts bashing my ugly hac
On Monday 13 November 2006 22:08, Andrew Barr wrote:
> What are my options for Windows Media Audio streams on the 770? Most
> Internet radio streams (I mean simulcasts of real broadcasts in this sense)
> are offered in (at least) this format, which is supported by free software
> (ffmpeg) up to ve
On Wednesday 18 October 2006 15:58, Amit Kucheria wrote:
> On Wed, 2006-10-18 at 13:00 +0300, ext Marius Gedminas wrote:
> > On Tue, Oct 17, 2006 at 11:50:03AM +0200, Malix wrote:
> > > Hi, after upgrade to maemo 2.0 I have a problem. Some times my 770
> > > reboot. This happen some times when I'm
On Wednesday 18 October 2006 16:26, Mike Frantzen wrote:
> > On Tue, Oct 17, 2006 at 11:50:03AM +0200, Malix wrote:
> > > Hi, after upgrade to maemo 2.0 I have a problem. Some times my 770
> > > reboot. This happen some times when I'm using the browser and every
> > > time I try to use Gizmo. For
Hello All,
What do you think about current wiki based application catalog? In my
opinion, it is quite a large page already, slow to open and hard to
navigate. As I see it now, maemo-apps.org looks like it may become an
interesting resource for maemo community in the future. But it lacks
content,
On Friday 22 September 2006 11:07, Kalle Vahlman wrote:
> 2006/9/22, Siarhei Siamashka <[EMAIL PROTECTED]>:
> > Hello,
> >
> > I wonder if there exists something like an applet for fast switching
> > between usb ethernet/mass storage device modes.
>
> Yes, t
Hello,
I wonder if there exists something like an applet for fast switching between
usb ethernet/mass storage device modes. Also it could provide some easy gui
interface for setting up networking over bluetooth.
Yes, I tried all these types of networking, but lately resorted only to wi-fi
as it i
On Wednesday 20 September 2006 01:12, Olivier ROLAND wrote:
> If your device is broken then mine is also.
> I don't think at all that we speak about (small) fraction because
> majority of users won't even notice the problem.
> My device seem stable until I stressed it. And stressed it is not a
> "
On 9/19/06, Kimmo Hämäläinen <[EMAIL PROTECTED]> wrote:
Yes, it would need to be reproducible in several different devices. The
guy here that tried to reproduce it currently thinks that Siarhei's unit
is broken.
Yes, I also think that the probability of my device being broken is
quite high. A
On 9/19/06, Frantisek Dufka <[EMAIL PROTECTED]> wrote:
Just few ideas:
software - bug is swapping/pagefault code?, bad ram timings?, too high
CPU clock?
That's an interesting idea, It seems to be worth trying to downclock
the device and check if it improves stability. Does anybody know how
to
On Tuesday 19 September 2006 00:03, you wrote:
[...]
> An interesting observation is that you need to gradually increase the size
> of tested memory block. You need to start with testing 20MB first, then you
> can try 25MB and so on up to 43MB. If you try to allocate and test a large
> block of
On Monday 11 September 2006 00:34, Olivier ROLAND wrote:
> > After playing with the device for some time, I got the same problem with
> > lzma program this evening. And memtester also confirms that the memory is
> > really defective :(
> >
> > # ./memtester 20
> > memtester version 4.0.5 (32-bit)
On Monday 11 September 2006 23:51, [EMAIL PROTECTED] wrote:
> When executing: cat /proc/cpuinfo I see the following:
> Processor : ARM926EJ-Sid(wb) rev 3 (v5l)
> BogoMIPS: 125.76
> Features: swp half thumb fastmult edsp java
> CPU implementer : 0x41
> CPU architecture: 5TEJ
>
On Sunday 10 September 2006 11:36, Olivier ROLAND wrote:
> Your test work fine on my device.
> I see that you run it from /media/mmc1so I guess you format your memory
> card with ext2.
> Mine still vfat so I can't. If you got same error when running from
> internal memory then your device is broke
Hello All,
I'm sorry for a long chunk of quoted text at the end of this message
(it describes the sympthoms of the problem), but looks like I got an
almost reliable proof that there is something wrong with the hardware
of my device :(
I tried to find some software that could be used for benchm
On Monday 21 August 2006 18:34, Charles 'Buck' Krasic wrote:
> Just in case you have not done it already, enabling swap in your device
> can help a lot to prevent out-of-memory errors.Maybe this will help
> with mplayer/gstreamer stability.
>
> I personally suspect a design flaw in the curren
On Monday 21 August 2006 10:45, Detlef Schmicker wrote:
> I had a look at the vncviewer and saw, that it is working in the sandbox
> in connection with vino (gnome vnc server). On the device the CoRRE
> encoding does not work.
>
> Probably it is a byte order problem. The code has a lot of byte ord
On Monday 21 August 2006 10:32, Eero Tamminen wrote:
> > Also I noticed that gstreamer is not very reliable, at least when using
> > it from mplayer. It can freeze or reboot the device sometimes. That's not
> > something that should be expected from high level API. If I detect some
> > reliable pa
On Friday 18 August 2006 22:16, you wrote:
> As the gstreamer got some attention in the mailing list, I think it is a
> good chance to remind that I'm still having problems with it too:
> http://maemo.org/pipermail/maemo-developers/2006-August/005060.html
>
> I need to know exact audio playing pos
On Friday 18 August 2006 11:21, Zeeshan Ali wrote:
> > - The licens of dsppcmsrc/sink is LGPL, can I find the source anywhere
> > - instead of raw data, it would be even better to use dspilbc.
> >Is there a way to store the captured data to a file, in a way it can
> >be played back again (
Hello All,
I'm trying to get current playing position from dspmp3sink, but
gst_element_query position() function fails. The same code works
fine for dsppcmsink.
Did anybody encounter such problem? What solution can be used?
___
maemo-developers mailin
On Tuesday 25 July 2006 09:01, you wrote:
> > http://www.internettablettalk.com/forums/showthread.php?t=2405
> >
> > Actually mplayer works surprisingly fast and has performance not much
> > inferior to default video player on Nokia 770 that is using DSP. And
> > that all is even without hardware
1 - 100 of 117 matches
Mail list logo
