On Sun, 25 Sep 2011 04:14:55 -0300 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> said:
going to have to kill off your dbus idea. reality is the pa dbus api is experimental (testing branch). i'm staring here at ubuntu 11.04 - no pulseaudio dbus service. as jeff said: <jeffdameth1> k-s: i heard the dbus interface is in a testing branch that will be merged with pulseadio 1.0. so this will take some time until adopted so... the only way to make it work is via the internal protocol - bare metal. unless you want to wait 2 years for it to stabilize, be adopted, released and actually on most peoples distributions. :) hands up those people who really desire to delay e17 release until then? :) yes the mapping of pa channels to the mixxer channels was cumbersome. i fixed it up to "work" and thus the id + 1 thnig so null (id 0) channels dont break stuff. as such the mixer infra doesn't quite cover everything pulse does, so really u'd need an alternate ui and infra setup. you can share the same gagdte and popup slider, but the rest would need to be different. > Hi all, > > Finally had time to check the pulseaudio mixer in E17 and while it > work, I do have some concerns regarding things below: > > - talking bare metal PA protocol is cumbersome, DBus API is the way > to go according to developers; > > - sticking (id + 1) to address cards and channels, while the actual > string name could be used (cosmetic, but would help debug); > > - not using the generic properties like device.class (to filter) and > device.description (to provide human-readable name); > > - not providing source handling and thus no way to control microphone; > > - pulse code was mixed into e_mod*.c, something I'd like to avoid. > Yes, what I did before was a compile-time module, thus symbols had to > be defined in the correct module. But it's easy to change to a struct > with defined pointers... e_mixer_pulse_setup() and > e_mixer_default_setup() are cumbersome and will get ugly if we need to > add a 3rd system :-( > > I've hacked a quick python-dbus test (attached) to show how it could > be done with DBus, it does cover all our cases and if done properly > will even create/remove elements on the fly given PA changes. > > What I noticed is that some changes to the internal sys_* API must be changed: > > - create sys_common.c to implement e_mixer_system* functions calling > plugins (alsa, dummy, pulse) > > - replace detection of "capture" mode from channel and create 3 > specific lists to be used by the app_mixer (dialog) > * sources (capture channel) > * sinks (output channel) > * users (or applications?) > > - replace hard coded 2-volume (left, right) with a list of values > and given names. However seems that PA will handle a single volume > value, applying to all the same. No idea how useful will be to open a > 5.1 video in VLC and have 6 sliders to show in E17. > > With these in place is easier to add a simpler PA and keep the same > infra. I'd use DBus here, but there is no issue to use current bare > metal code... just more work (now and in the long term). > > If people agree I can try to do these sys_* API changes soon and help > with the dbus api. > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
