"This newsletter contains confidential information and constitutes a valuable benefit provided by Nokia to you as a Forum Nokia Developer member. This newsletter should not be shared with or forwarded to persons who are not employees of your company. The content of this newsletter is subject to the confidentiality terms of the Forum Nokia Developer "Non-Disclosure Agreement" (NDA) signed by member companies. All Forum Nokia Developer members a

any of you guys messed with osso-backup? as in editing the stuff in zip files (backing up without password), repacking it and then getting osso-backup to set it up according to one's modified preferences?

its the settings that I got osso-backup to backup. I haven't yet installed backupmenu (hence I'm trying to setup a backup clone in case something seriously gets messed up on my main one). The settings if I were to restore that onto my other N900 the Display configurations under Settings automatically freezes Settings app

thats what i meant with design flaw .. technically each device should authenticate properly with each other and the network .. if not its like operating a pirate radio transmitter, when you do and get catched then you get sued and have to pay high fines

SpeedEvil: there'll *always* be people infringing copright. That has never been the problem, the problem is that the media business has stopped delivering services that people are willing to buy once they actually get money to do so.

The fundamental problem is that radio is a shared resource - anyone transmitting on an unauthorised channel on a GSM networks allocation will knock off up to 16 calls. Some of which may be emergency calls.

Sure - it's not. The issue is that your average teenager - who is infringing on copyright over P2P is not likely to see a major difference between doing that, and running a 'free data transfer to your friends' app.

dangergrrl: If you are 2km from a cell-tower, and transmit to your friend without negotiating with that cell-tower, you will knock everyone else further than 1km or so on the same channel off the network.

i think the problem is not the closed gsm stack, nokia shows that it is possible to provide a free userland with closed parts e.g. for radio, grafic. but why nobody build such stuff with --usable --customizable

dangergrrl: scenario: N900 comes with FOSS GSM stack, some dude is patching it to fix the "doesn't reregister after long time in bunker" issue, seems to work, everybody is installing it. 3 Months later the newspapers come up with "Mysterious GSM failures that tore down half of USA got spotted - some 'fix' in a Nokia phones SW caused timing issues in the celltowers"

javispedro: c) you need proper amixer settings anyway, but it seems there is just NO "scenarios" (they call it scenarios in OM/SHR) to feed to either alsactrl or amixer, to make mic and speaker output work

yeah, i do like that interface actually, it would work very well as either a fullscreen brightness changer on a handset (the taskbar icon is clicked and it pops up and essentially takes the whole screen) or as a widget on a tablet device

[2011-05-25 18:02:08] <derf> No one actually uses the system clock to sync audio and video. [2011-05-25 18:03:03] <DocScrutinizer> derf: I don't even need to start to show you about your prev staement being false

MohammadAG, Lo, I'm using your modified apt package so I can download packages normally restricted to having to use the Ovi Store (handy when you want a one-liner apt-get to get all your apps back)... are all the Ovi stuff in the maemo.nokia.com repo? like I'm found bounce and angrybirds but not the angry birds levels or even firefox

MohammadAG, any easy way of finding the corresponding names? (apt-cache search doesn't seem to be helping me much) also what about the pay-for ovi apps? they in there too? (paid for the levels you see)

Considering the architecture for most video players were designed when P3-500 was a reasonable cpu in the "performance" class, where resampling 44.1kHz stereo took 30% CPU, it was never even considered :)

ShadowJK: it's basically irrelevant what's your master clock. The point is you have to nominate just ONE master clock, and sync all the media streams to that, by either inserting/dropping whole audio snippets (packages) or single samples/frames (which is a sort of poor man's resampling), or by dynamically adjusting the slave clock of the media stream running out of sync. Basically same applies to video. Esp if you're playing a 25fps video

defininig it only works within the limitations of the harware and the plugins. Every plugin that does something non-trivial adds a buffer. From buffer fill you can calculate a time, but that time is "time until exception", get delay is "time until buffer tail comes out of speaker"

I want to share my home's wireless connection from my n900 -> a computer with no wifi, but with bluetooth and usb. I've used http://wiki.maemo.org/USB_networking#Host_USB_Network_Configuration to connect the devices via usb, the computer is running Ubuntu 11.04. I'm hoping someone here might know how to do it and is willing to help me set it up.

My N900 is dead and has been for a few days now. I thought the battery was empty, because when I started it, it suddenly shut down after a few seconds. It now looks like the usb plug may be damaged, but I've connected the USB cable and the LED flashes read very shortly and every second or so.

it is suggested that this might be a security issue caused by turning the device on and off many times and that reflashing it might do the trick. The question, then, becomes: how? I can't get any life in it at all.

jo-erlend, no it doesn't indicate a security measure. It indicates that there is a charging problem. The problem could be your dc adapter, cable, plug, port, n900, battery terminals, battery pins, or battery

no doubt, it is the plug in the phone that's faulty. I wiggled a little bit and I got that orange light indicating that it was charging and that little shake to indicate that it was switching on, but then it died.

ShadowJK: so use a larger buffer spec when opening the ALSA device, and be sure your delay is N-1 segments * samplerate * frames/segment when your app gets signalled to deliver the next chunk of data - after initial fill up of whole buffer with N segments of data

All I want to know is how many bytes are in the buffer, and how much delay there is between buffers empty and sound from speakers stopping (the last one is often sufficiently close to 0 that it doesn't matter). get_delay is supposed to be both combined

if your video is still in timeframe of segment one when alsa asks for segment 3 then you're late on video playback. when you're a large way into timeframe 2 or even started 3 then you'Re too fast with video -do whatever you need to correct it

pulseaudio only works or adds a benefit when it has exclusive access to the audio device, because then it can actually get the parameters it asks for, and provide accurate timing and buffer fill info to its clients. The additional benefit is of course that it has documentation, and that the documentation is comprehensible to more people than the ones who wrote it ;p

Arguably the effort spent on pulseaudio could've been spent on fixing alsa bugs, alsa api, and alsa docs instead, but that brings us back to to alsa being incomprehensible to everyone except those who wrote it, and a few others