The *right* way to do a2dp
Hello, I just got a pair of bluetooth headphones and was wondering what is the right way to enable a2dp. I really like how maemo handles routing all the audio to the headphones when they're connected but it sounds like crap. I've seen various scripts that would enable a2dp output via alsa but I was wondering if there's a more generic way to do it so that it would be available to all applications. Also, is there any documentation that details how sound is routed to bluetooth headphones once connected? I'm kinda curious to see how it works. Thanks, nick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Default nice value setting
On June 17, 2009 05:03:32 am Frantisek Dufka wrote: > Henrik Hedberg wrote: > > If it is really crucial for the application to have higher priority, > > maybe it could be installed as setuid root. In that way, it could first > > set priority from 0 to -1, and then drop the privileges. > > Or postinstall script could add some helper to sudoers which could raise > priority when started from inside the application. I think Vagalume uses > this trick. Thanks guys for all the clever solutions to the problem. @Frantisek I'm using OS2008 version 5.2008.43-7 but like you said that bug probably won't get fixed. And for applications that need to go from -1 to 0 that's very easy, it's probably not even worth fixing... Thanks again, nick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Default nice value setting
Hi, Is there a way to specify a default nice value for an application on maemo? I noticed that if an application is launched by the menu directly from an executable (using the Exec variable in the .desktop file) it gets a nice value of -1. But, if the application is started over D-Bus (using the X-Osso-Service variable in the .desktop file) it gets a nice value of 0. The application I'm working on needs at least a nice value of -1 or else it becomes unusable. Is there a way to make this happen while still being able to start the application over D-Bus? Thanks, nick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Playbin volume bug for OGG and WMA playback
This has been bugging me for quite some time and I think I've finally gotten to the bottom of it. In this message I present my (limited) understanding of how gstreamer works, what this annoying bug is, potentially why this bug occurs and perhaps how to fix it. Lets get on with it. There are several ways that audio gets played through gstreamer, the audio can either be decoded on the device's processor or it can be offloaded to one of a few different hardware decoders (DSPs). Gstreamer's playbin provides a very easy way for the developer to not have to worry about writing pipelines for every possible type of audio that can be played back by their application. For MP3 and AAC audio, gstreamer uses hardware decoding provided by dspmp3sink and dspaacsink respectively. OGG and WMA audio must first be decoded to PCM (decoderbin takes care of this nicely) and then get passed to dsppcmsink. On maemo, the audio sinks (dspmp3sink, dspaacsink, and dsppcmsink) all have their own "volume" property (an integer between 0 and 2^16) and another property named "fvolume" which seems to simply be volume/2^16 (a float between 0 and 1). Either of these can be set, they accomplish the same goal; controlling the volume level. Gstreamer also provides a nice volume control element that you can add in a pipeline to presumably control the volume before it gets to the audio sink in the event that the audio sink doesn't have a volume property. The documentation says that the volume control element can take a value from 0 to 10 but during my testing it seems that anything over 1 distorts. So in reality you'll only be using it from 0 to 1. The Problem. If you create a pipeline using playbin to playback an ogg or wma file, you end up with a volume control element stuck right before dsppcmsink (see image #1). In this case playbin's volume property is connected to both the volume control element and the dsppcmsink "fvolume" property. This is were it gets weird, when you set the volume property of the playbin, the volume control element gets set to that exact number BUT the dsppcmsink's "fvolume" property gets set to one tenth of that number. Big deal, right? Wrong. This means that you can only set the output volume to about 10% before it begins to distort. For example, if I set the playbin's volume property to 3 (referring again to image #1), the volume control element gets set to 3 (we have distortion at this level) and the dsppcmsink's "fvolume" property is set to 0.3. The maximum value we can set the playbin's volume property is 1 (instead of 10, like when playing mp3s), anything else sounds bad. The Solution. There are two ways I can think of to solve this problem. Make the volume control element and the dsppcmsink share the same volume property or remove the volume control element entirely for playbins. I just don't really know how to go about fixing it... I suspect this issue has something to do with the way dsp sinks work on maemo's gstreamer. When using a dspmp3sink or a dspaacsink via a playbin, the volume property is a number between 0 and 10 which gets divided by 10 and used as the sink's "fvolume" value (see image #2). Could it be that someone simply forgot to divide by 10 in the volume control element code? Here are some gstreamer pipelines to help you experiment with this problem yourself (use these on your NIT). The following two pipelines sound exactly alike (very distorted), the first using playbin and the second using decodebin, a volume control element and dsppcmsink. The second is essentially the same as what playbin creates, which is wrong. gst-launch-0.10 playbin uri=http://tinyurl.com/524rwv volume=6 gst-launch-0.10 gnomevfssrc location=http://tinyurl.com/524rwv \ ! decodebin ! volume volume=6 ! dsppcmsink fvolume=0.6 Now if we change the volume element's volume setting from 6 to 0.6, there's no distortion: gst-launch-0.10 gnomevfssrc location=http://tinyurl.com/524rwv \ ! decodebin ! volume volume=0.6 ! dsppcmsink fvolume=0.6 These images were generated on an n810 running Maemo 4.1 with the ogg-support 0.9 and gstreamer version 0.10.22 (the version that comes with Maemo isn't able to generate images of pipelines). Image #1 (OGG file, playbin, volume=3): http://imgur.com/H1Uiy.png Image #2 (MP3 file, playbin, volume=3): http://imgur.com/oEB4Y.png I'm pretty sure this is a bug, but if not please let me know what I'm doing wrong here. Or perhaps someone could explain how Nokia's media player handles volume or pipeline creation since it doesn't seem to experience this bug. It would be a shame to have to force the application developer to work around this problem by either worrying about creating different pipelines for different media types or just limiting playbin's volume to 1. I guess my point is, we should be able to take advantage of gstreamer's awesome playbin simplicity on Maemo. Thank you for your time and patience, nick ___ maemo-develo
[GSOC Proposal] gPodder and Panucci integration
Hello, I know it's late to submitting a proposal but I didn't think I'd be able to participate in the GSOC until today. Please let me know what you think, nick gPodder and Panucci integration for Maemo As it stands downloading and listening to podcasts on Maemo is a tad sketchy. The two best suited tools for the job at the moment are gPodder and Panucci. gPodder is a very feature-rich podcast aggregator and Panucci is a small, bookmarking media player built specifically with podcast and audiobook listeners in mind. The problem is that they don't play very well with each other; this proposal will change that. I intend to make gPodder, Panucci, and a NIT the best combination of hardware and software that a podcast listener can use to enjoy their shows. What major things need to be done in order to achieve this goal? 01) gPodder needs more of an MVC architecture so that changes to the database can easily be propagated to the GUI. 02) gPodder needs a rich API that can be accessed over d-bus. 03) Panucci will have to be able to interact with this new API. Things that are necessary for proper Maemo integration: 04) gPodder should be aware of Maemo's network layer and pause downloads when the network connection is interrupted. 05) Maemo backup integration (gPodder bug #321) 06) Add a gPodder option to restrict downloading of large files when the user is on a cellular Internet connection (gPodder bug #273) 07) In gPodder, delete episodes in a separate thread as not to lock up the GUI (gPodder bug #268) 08) Panucci should support streaming of podcasts (now that gPodder supports streaming) 09) Scrolling metadata labels for Panucci. 10) Translations for Panucci. The specifics: For the longest time gPodder has been relying on code in the GUI to do things that really should be taking place behind the scenes. Lately Thomas Perl (the gPodder lead developer) and others have started moving chunks of code into their own respective modules but it's far from complete. I propose to finish off where they left off and make gPodder a prime example of MVC. This mundane task is necessary for the completion of the next step, the d-bus API. I predict that this task will take the longest to complete, on the order of 3 to 4 weeks. The gPodder d-bus API will be relatively large to make it easier for other application developers to interface with gPodder in a language-neutral way. Although it is currently possible to import gPodder's python modules this method doesn't really work while gPodder is running. Features of this API will be things like adding/removing feeds, accessing all sorts of metadata and remotely being able to change settings. This will take on the order of 1 to 2 weeks to complete. The most important step is finally integrating both gPodder and Panucci. Once the gPodder d-bus API is complete it should be fairly trivial to connect the two. Some already community-requested features (from ITT) include marking episodes as played in gPodder (once a certain threshold has been reached in Panucci), getting cover art and episode metadata to be displayed in Panucci and being able to delete episodes from Panucci and propagating that change to the gPodder database. Also, gPodder would be able to detect whether Panucci is installed and if it is there would be additional menu items to allow the user to add the file to a Panucci playlist. This step will probably take on the order of 1 to 2 weeks to complete. Since Panucci is still a pretty young project it still needs a bit of polish when it comes to the Maemo platform. One of the biggest requests is scrolling labels (much like on an iPod) for artist and title information. Since there is no native scrolling-label widget in GTK I'll have to come up with something to make this happen. The label will have to be aware of the state of the device's screen in order to save power by not moving the label if the screen is off. This should take no more than a week. In order to fully take advantage of the Maemo platform I intend to make gPodder network-aware thus if the network connection is lost while downloading episodes or refreshing the feed cache gPodder can pause the downloads in question and abort the feed cache update gracefully. The "pausing" of downloads will be very simple thanks to some new download manager code that Thomas is working on at the moment, all I'd have to do is interface with the Maemo network stack. This should take a day or two at the most. Another problem with downloading podcasts on an Internet tablet is the large amounts of bandwidth required for long episodes. If the user is on a cellular connection this can be quite costly and for that reason I plan to implement a configuration option to restrict downloading of large episodes unless the user is on a wifi connection (this will of course be optional and up t
Reliably Getting Position Information From Gstreamer
Hello, I'm trying to figure out if there's a bug in Maemo's gstreamer or if I'm doing something wrong. It seems that if I seek too many times in rapid succession gstreamer will report a false position (normally 0) when query_position is called. I hacked together a sample player[1] that demonstrates this behavior (from the pygst tutorial example 3.1). Once the file starts playing seek_from_current is called once every 0.1 seconds. On a regular Linux desktop it works perfectly, but on Maemo the song will end up being reset to 0 every few seconds (this is because query_position is reporting a wrong number that's 0 or close to it). Am I missing something? Is there a specific message I must wait for before querying the player again? Or is this just a bug? Thanks, nick [1] http://nikosapi.org/stuff/gst-seek-test.py ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Stock GTK Icons
Hello, How come the following short pygtk program doesn't display it's stock icon on maemo? Am I doing something wrong or is this intentional? #!/usr/bin/env python import gtk w = gtk.Window() b = gtk.Button(gtk.STOCK_NEW) b.set_use_stock(True) w.add(b) w.show_all() gtk.main() ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Getting button press events from the "zoom" buttons when locked
Hello, I'm currently working on a small audio player application and I'd like to know if it's possible to get access to the "zoom" buttons (+/- on the top-left of the n810) even when the device is locked. The reason being that I'd like to use those to change the volume without having to go through the process of unlocking and locking the device each time. Thanks, nick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
