Re: [E-devel] pulseaudio in e17
On Tue, Sep 27, 2011 at 23:22, David Seikel onef...@gmail.com wrote: On Tue, 27 Sep 2011 15:14:44 -0500 Jeff Hoogland jeffhoogl...@linux.com wrote: I am the only one that has to cringe every time he hears the words pulse audio? I actually like it. :-P Definitely looks like you better get used to it though. Don't think it's going away any time soon. Raster does not seem keen on doing a new audio system again. OSSv4 works fine at least for me (Having software mixing for years, and no lock with flash or whatever, been able to change volume per application…). I don't care about pulseaudio, just don't make it mandatory. -- Boris Faure -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] pulseaudio in e17
On Wed, 28 Sep 2011 09:29:05 +0200 Boris Faure bill...@gmail.com wrote: On Tue, Sep 27, 2011 at 23:22, David Seikel onef...@gmail.com wrote: On Tue, 27 Sep 2011 15:14:44 -0500 Jeff Hoogland jeffhoogl...@linux.com wrote: I am the only one that has to cringe every time he hears the words pulse audio? I actually like it. :-P Definitely looks like you better get used to it though. Don't think it's going away any time soon. Raster does not seem keen on doing a new audio system again. OSSv4 works fine at least for me (Having software mixing for years, and no lock with flash or whatever, been able to change volume per application…). I don't care about pulseaudio, just don't make it mandatory. don't worry, I hate it far more than you do. -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] pulseaudio in e17
On Wed, Sep 28, 2011 at 03:07, Carsten Haitzler ras...@rasterman.com wrote: On Tue, 27 Sep 2011 23:44:06 +0200 Thomas Gstädtner tho...@gstaedtner.net said: if we take your view that the only thing that matters in a release is sitting and waiting 6+ months for a distro to package it, then why do we care about release at all? reality is this: we release as source tarballs day 1 and there will be the first major group of users that take this and use that and need it to work. that means it must work TODAY. if it doesn't work today no devs can even test it. no PA 1.0 here - no dbus API. if it wasn't for me testing it against an installed and working today distro and changing and fixing code - the PA support wouldn't work right. mike did some awesome work. he missed some critical small things and some integration work. i CAN'T test and fix against a PA 1.0 today... and mike can't because he doesn't have it either - that's WHY he reverse engineered the PA protocol. looking at the number of other people working on the e17 release todo list... actually getting things finished - well... those DOING the work that call the shots. those DOING the code to support PA don't have a dbus API... TODAY - when the code NEEDS TO BE DONE... and so... it didn't get done and won't be worked on by those people. if others wish to step up and work on the release todo - then maybe they can implement it if they have a dbus API available to test against. i'd welcome people stepping up and doing things. but the voices of those who worked on it says no dbus API here.. so moot. not going to bother. what is there now works. what's the fuss?. if the issue is that OMG!~ they may break internal protocol!!! use dbus!!! it won't break. please tell me that the networkmanager dbus api never broke. or connman... or... yeah right. i thought so. :) (it seems to me that people who use dbus love to break api's much more as the effects are less drastic than a c api break - where u get crashes or simply apps not starting at all, but in dbus land features just stop working or malfunction, so the error state degredation is less). so even if distros pick e up on 6+ months after release.. the PA code there will still work. or should. i don't see that going away in a hurry. now even after source tarballs we will have packages for fedora, ubuntu, debian etc. that are made within weeks of src release (or days) and so are available via extra repositories (or in debian testing/unstable which is what people actually use), so let's be realistic... e needs to work HERE. in this situation. we can't just say oh well it doesn't work for 90% of potential users today but as long as everyone upgrades their distribution the instant they come out from distro vendors AND those distros ALL pick up PA 1.0 - sure over 3, 6, 9, 12 months e may being to be usable... so we just will ignore the problem and throw out work already done so we can ensure we get a reputation for releasing stuff that is not usable so maybe in 12 months 50% of possible users might have e work right (with audio). why 50%? u REALLY think people upgrade their distribution instantly? i don't know what bizarre world you live in but they don't. they often lag behind the actual release (in fact the majority do i'd say) by at least 3-6 months or more. the majority of possible users may very conceivably be on a distro released 6 or 12 months ago. reality is we have to work for them. so that means working with what is out TODAY (or even last year). Ok, let's get realistic: _If_ e17 should go stable later this or early next year, it will take a while until distros include it in their trees at all, lat alone stabilize it (for the distros that maintain stable branches). So here's a list of the major distros including a) the current release with its PA version b) the first release e17 could be included in should it be release in the next 6 months c) the first release that will have PA with dbus support Debian a) stable/squeeze: PA 0.9.21 b) unstable/sid: PA 0.9.23 c) unkown (likely not before 7.0, but then again, e17 won't make it either.) Fedora a) f15: PA 0.9.22 b) f16: PA 0.9.23 c) unknown (probably fast-tracked to f16, more likely coming in f17) Gentoo a) current: PA 0.9.23 b) ~testing: PA 1.0 c) ~testing (PA 1.0 will be stable before EFL, let alone e17) OpenSuse a) 11.4: PA 0.9.22 b) 12.1: PA 0.99/1.0 c) 12.1 (next release will be early 2012 and include PA 1.0) Ubuntu a) 11.04: PA 0.9.22 b) 11.10: PA 0.99/1.0 c) 11.10 (upcoming release will include PA1.0) In conclusion: even if the e17 release happens very soon, it will not be included in any stable tree this year, and very likely not even next year. In the non-stable trees, of the major distros Ubuntu, OpenSuse, Gentoo all already have PA 1.0 (or a 0.99 prerelease) and likely have it stabilized before 2012. Fedora might, as they usually stabilize
Re: [E-devel] pulseaudio in e17
On Sun, Sep 25, 2011 at 5:00 AM, Carsten Haitzler ras...@rasterman.com wrote: 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. PA 1.0 was released today... and what a shame WE avoiding projects just because they were not released, in that sense people should still avoid Elm and E17? :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] pulseaudio in e17
On Tue, 27 Sep 2011 12:12:22 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Sun, Sep 25, 2011 at 5:00 AM, Carsten Haitzler ras...@rasterman.com wrote: 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. PA 1.0 was released today... and what a shame WE avoiding projects just because they were not released, in that sense people should still avoid Elm and E17? :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel You may be familiar with the phrase 'apples and oranges.' If not, see this link for further reading: http://en.wikipedia.org/wiki/Genetic_fallacy We aim to support the current version of pulse at the time of E17's release. Unless we delay the release of E17 another few years, the current version of pulse will NOT be 1.0. It will be some 0.9.X version with no dbus api and an irregular (at best) library api which creates a large number of unwanted hard dependencies. Going with the native protocol allows compatibility with pulseaudio versions down to 0.9.16, and GUARANTEES future compatibility with versions 1.0. There's no real downside to using native protocol for quick mixer module additions aside from the amount of work that I personally have to do in order to reimplement the protocol in a usable form. Knowing all this, if you really want to rewrite the mixer module to have full 1.0 dbus pulseaudio integration then by all means do so. But let me know beforehand so I don't waste any more time looking at the awful codebase which is pulse internals. -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] pulseaudio in e17
I am the only one that has to cringe every time he hears the words pulse audio? On Tue, Sep 27, 2011 at 3:08 PM, Mike Blumenkrantz m...@zentific.comwrote: On Tue, 27 Sep 2011 12:12:22 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Sun, Sep 25, 2011 at 5:00 AM, Carsten Haitzler ras...@rasterman.com wrote: 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. PA 1.0 was released today... and what a shame WE avoiding projects just because they were not released, in that sense people should still avoid Elm and E17? :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel You may be familiar with the phrase 'apples and oranges.' If not, see this link for further reading: http://en.wikipedia.org/wiki/Genetic_fallacy We aim to support the current version of pulse at the time of E17's release. Unless we delay the release of E17 another few years, the current version of pulse will NOT be 1.0. It will be some 0.9.X version with no dbus api and an irregular (at best) library api which creates a large number of unwanted hard dependencies. Going with the native protocol allows compatibility with pulseaudio versions down to 0.9.16, and GUARANTEES future compatibility with versions 1.0. There's no real downside to using native protocol for quick mixer module additions aside from the amount of work that I personally have to do in order to reimplement the protocol in a usable form. Knowing all this, if you really want to rewrite the mixer module to have full 1.0 dbus pulseaudio integration then by all means do so. But let me know beforehand so I don't waste any more time looking at the awful codebase which is pulse internals. -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ~Jeff Hoogland http://jeffhoogland.com/ Thoughts on Technology http://jeffhoogland.blogspot.com/, Tech Blog Bodhi Linux http://bodhilinux.com/, Enlightenment for your Desktop -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] pulseaudio in e17
On Tue, Sep 27, 2011 at 5:08 PM, Mike Blumenkrantz m...@zentific.com wrote: On Tue, 27 Sep 2011 12:12:22 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Sun, Sep 25, 2011 at 5:00 AM, Carsten Haitzler ras...@rasterman.com wrote: 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. PA 1.0 was released today... and what a shame WE avoiding projects just because they were not released, in that sense people should still avoid Elm and E17? :-) We aim to support the current version of pulse at the time of E17's release. Unless we delay the release of E17 another few years, the current version of pulse will NOT be 1.0. It will be some 0.9.X version with no dbus api and an irregular (at best) library api which creates a large number of unwanted hard dependencies. Going with the native protocol allows compatibility with pulseaudio versions down to 0.9.16, and GUARANTEES future compatibility with versions 1.0. There's no real downside to using native protocol for quick mixer module additions aside from the amount of work that I personally have to do in order to reimplement the protocol in a usable form. Knowing all this, if you really want to rewrite the mixer module to have full 1.0 dbus pulseaudio integration then by all means do so. But let me know beforehand so I don't waste any more time looking at the awful codebase which is pulse internals. As I said I have no problems with not using DBus, given that I'm not the one that would care about doing it. I'll need to figure out when I'll have time to do this, but likely what I will do is: - create another mixer with a copy of original code, pre-pulse - make that code take runtime plugins, as opposed to compile time - extend the API to consider N volumes, instead of left/right - add callbacks to notify of changes, like removal of cards, sinks or sources - change the main list to query sinks, sources and applications. Instead of checking for capture or not. - send the code to you - wait you to test - commit to svn Does it sound like a good plan? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] pulseaudio in e17
On Tue, 27 Sep 2011 12:12:22 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Sun, Sep 25, 2011 at 5:00 AM, Carsten Haitzler ras...@rasterman.com wrote: 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. PA 1.0 was released today... and what a shame WE avoiding projects just because they were not released, in that sense people should still avoid Elm and E17? :-) totally different things. we implemented PA support not because we want to.. but because we HAVE to. it is FORCED on us as a result of distributions shipping with PA all enabled and if we ignore it, some people end up with muted audio, no matter how much you fiddle with alsa mixers. so our job is to support the PA that *IS* there NOW, so we don't end up with large numbers of users going when I use E my audio is broken. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] pulseaudio in e17
On Tue, Sep 27, 2011 at 5:22 PM, Carsten Haitzler ras...@rasterman.com wrote: On Tue, 27 Sep 2011 12:12:22 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Sun, Sep 25, 2011 at 5:00 AM, Carsten Haitzler ras...@rasterman.com wrote: 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. PA 1.0 was released today... and what a shame WE avoiding projects just because they were not released, in that sense people should still avoid Elm and E17? :-) totally different things. we implemented PA support not because we want to.. but because we HAVE to. it is FORCED on us as a result of distributions shipping with PA all enabled and if we ignore it, some people end up with muted audio, no matter how much you fiddle with alsa mixers. so our job is to support the PA that *IS* there NOW, so we don't end up with large numbers of users going when I use E my audio is broken. the muted sound can be resolved by using the new libcanberra, it's used during the boot to provide sounds at early boot... and takes care to unmute the system :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] pulseaudio in e17
On Tue, 27 Sep 2011 15:14:44 -0500 Jeff Hoogland jeffhoogl...@linux.com wrote: I am the only one that has to cringe every time he hears the words pulse audio? I actually like it. :-P Definitely looks like you better get used to it though. Don't think it's going away any time soon. Raster does not seem keen on doing a new audio system again. Now, if some of those developers that hated it actually worked to improve it, we might have less people that hate it. In the end, it's a good idea in principle, it sucked in the early stages when distros where falling in love with it, but it sucks a lot less now. It tends to be that those that hated in in the early days wipe it off their systems now without a thought, and might not be getting a chance to see how much it has improved. Just saying. Now if simultaneous output did not make the webkit in SL viewers crash, it would be perfect. B-) Or, sigh, I could actually capture the sound output from the game I'm developing in screen movie makers. Screen movie makers tend to be generally bad though, seems only one of them actually works here. shrugs -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] pulseaudio in e17
On Tue, Sep 27, 2011 at 22:22, Carsten Haitzler ras...@rasterman.com wrote: On Tue, 27 Sep 2011 12:12:22 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Sun, Sep 25, 2011 at 5:00 AM, Carsten Haitzler ras...@rasterman.com wrote: 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. PA 1.0 was released today... and what a shame WE avoiding projects just because they were not released, in that sense people should still avoid Elm and E17? :-) totally different things. we implemented PA support not because we want to.. but because we HAVE to. it is FORCED on us as a result of distributions shipping with PA all enabled and if we ignore it, some people end up with muted audio, no matter how much you fiddle with alsa mixers. so our job is to support the PA that *IS* there NOW, so we don't end up with large numbers of users going when I use E my audio is broken. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel Ok, let's get realistic: _If_ e17 should go stable later this or early next year, it will take a while until distros include it in their trees at all, lat alone stabilize it (for the distros that maintain stable branches). So here's a list of the major distros including a) the current release with its PA version b) the first release e17 could be included in should it be release in the next 6 months c) the first release that will have PA with dbus support Debian a) stable/squeeze: PA 0.9.21 b) unstable/sid: PA 0.9.23 c) unkown (likely not before 7.0, but then again, e17 won't make it either.) Fedora a) f15: PA 0.9.22 b) f16: PA 0.9.23 c) unknown (probably fast-tracked to f16, more likely coming in f17) Gentoo a) current: PA 0.9.23 b) ~testing: PA 1.0 c) ~testing (PA 1.0 will be stable before EFL, let alone e17) OpenSuse a) 11.4: PA 0.9.22 b) 12.1: PA 0.99/1.0 c) 12.1 (next release will be early 2012 and include PA 1.0) Ubuntu a) 11.04: PA 0.9.22 b) 11.10: PA 0.99/1.0 c) 11.10 (upcoming release will include PA1.0) In conclusion: even if the e17 release happens very soon, it will not be included in any stable tree this year, and very likely not even next year. In the non-stable trees, of the major distros Ubuntu, OpenSuse, Gentoo all already have PA 1.0 (or a 0.99 prerelease) and likely have it stabilized before 2012. Fedora might, as they usually stabilize core-packages much more quickly than other distros, Debian of course won't, but sid will have 1.0 support soon. P.S.: List, please don't be insulted if I didn't include your distro, it was not my goal to do you any psychological harm. I included those 5 because I assume that they are the original distros which cover the largest userbase. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] pulseaudio in e17
On Tue, 27 Sep 2011 23:44:06 +0200 Thomas Gstädtner tho...@gstaedtner.net said: if we take your view that the only thing that matters in a release is sitting and waiting 6+ months for a distro to package it, then why do we care about release at all? reality is this: we release as source tarballs day 1 and there will be the first major group of users that take this and use that and need it to work. that means it must work TODAY. if it doesn't work today no devs can even test it. no PA 1.0 here - no dbus API. if it wasn't for me testing it against an installed and working today distro and changing and fixing code - the PA support wouldn't work right. mike did some awesome work. he missed some critical small things and some integration work. i CAN'T test and fix against a PA 1.0 today... and mike can't because he doesn't have it either - that's WHY he reverse engineered the PA protocol. looking at the number of other people working on the e17 release todo list... actually getting things finished - well... those DOING the work that call the shots. those DOING the code to support PA don't have a dbus API... TODAY - when the code NEEDS TO BE DONE... and so... it didn't get done and won't be worked on by those people. if others wish to step up and work on the release todo - then maybe they can implement it if they have a dbus API available to test against. i'd welcome people stepping up and doing things. but the voices of those who worked on it says no dbus API here.. so moot. not going to bother. what is there now works. what's the fuss?. if the issue is that OMG!~ they may break internal protocol!!! use dbus!!! it won't break. please tell me that the networkmanager dbus api never broke. or connman... or... yeah right. i thought so. :) (it seems to me that people who use dbus love to break api's much more as the effects are less drastic than a c api break - where u get crashes or simply apps not starting at all, but in dbus land features just stop working or malfunction, so the error state degredation is less). so even if distros pick e up on 6+ months after release.. the PA code there will still work. or should. i don't see that going away in a hurry. now even after source tarballs we will have packages for fedora, ubuntu, debian etc. that are made within weeks of src release (or days) and so are available via extra repositories (or in debian testing/unstable which is what people actually use), so let's be realistic... e needs to work HERE. in this situation. we can't just say oh well it doesn't work for 90% of potential users today but as long as everyone upgrades their distribution the instant they come out from distro vendors AND those distros ALL pick up PA 1.0 - sure over 3, 6, 9, 12 months e may being to be usable... so we just will ignore the problem and throw out work already done so we can ensure we get a reputation for releasing stuff that is not usable so maybe in 12 months 50% of possible users might have e work right (with audio). why 50%? u REALLY think people upgrade their distribution instantly? i don't know what bizarre world you live in but they don't. they often lag behind the actual release (in fact the majority do i'd say) by at least 3-6 months or more. the majority of possible users may very conceivably be on a distro released 6 or 12 months ago. reality is we have to work for them. so that means working with what is out TODAY (or even last year). Ok, let's get realistic: _If_ e17 should go stable later this or early next year, it will take a while until distros include it in their trees at all, lat alone stabilize it (for the distros that maintain stable branches). So here's a list of the major distros including a) the current release with its PA version b) the first release e17 could be included in should it be release in the next 6 months c) the first release that will have PA with dbus support Debian a) stable/squeeze: PA 0.9.21 b) unstable/sid: PA 0.9.23 c) unkown (likely not before 7.0, but then again, e17 won't make it either.) Fedora a) f15: PA 0.9.22 b) f16: PA 0.9.23 c) unknown (probably fast-tracked to f16, more likely coming in f17) Gentoo a) current: PA 0.9.23 b) ~testing: PA 1.0 c) ~testing (PA 1.0 will be stable before EFL, let alone e17) OpenSuse a) 11.4: PA 0.9.22 b) 12.1: PA 0.99/1.0 c) 12.1 (next release will be early 2012 and include PA 1.0) Ubuntu a) 11.04: PA 0.9.22 b) 11.10: PA 0.99/1.0 c) 11.10 (upcoming release will include PA1.0) In conclusion: even if the e17 release happens very soon, it will not be included in any stable tree this year, and very likely not even next year. In the non-stable trees, of the major distros Ubuntu, OpenSuse, Gentoo all already have PA 1.0 (or a 0.99 prerelease) and likely have it stabilized before 2012. Fedora might, as they usually stabilize core-packages much more quickly than other distros, Debian of course won't, but sid will have 1.0 support soon. P.S.: List, please don't be
Re: [E-devel] pulseaudio in e17
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
Re: [E-devel] pulseaudio in e17
On Sun, 3 Jul 2011 20:56:29 -0400 Mike Blumenkrantz m...@zentific.com said: you could write a small executable to query/set the mixer props - and that small binary can use glib... now... if there is an api to swizzle with PA. there thus MUSt be a protocol it talks to PA. this protocol must obviously then exist in some form (be it a plain socket, a dbus api, etc.) so.. my guess is you missed something? heyo, I spent several hours today examining pulseaudio, planning to start hacking on the mixer code. What I discovered is very depressing: * libpulseaudio REQUIRES glib and REQUIRES glib main loop. literally. they're params for pa_context_new(). this is doable, but not at all in the context of our current mixer module. * there is a full dbus api for pulseaudio. luckily, the geniuses working on it aren't releasing it: http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-June/010160.html * I looked into reverse engineering the control protocol by manipulating a socket that PA uses: also a no-go since the tcp protocol must be manually enabled by editing a config file. * pulse has a number of library interfaces to work with. none of these let you manipulate volume mixers. as far as I can see, unless the dbus api comes out tomorrow (PA 1.0) and everyone magically adopts it overnight we should probably drop this item from the 1.0 TODO, and imo permanently unless someone wants to rewrite the whole mixer to function with both: * multiple driver backend support (alsa+pulse+oss+jack+wtfelse) * async driver APIs (such as pulse/jack) support it's been a huge headache learning even this much, so unless someone is more masochistic than me, I strongly suggest marking this WONTFIX. -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- 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-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - 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-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] pulseaudio in e17
On Mon, 4 Jul 2011 11:56:31 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sun, 3 Jul 2011 20:56:29 -0400 Mike Blumenkrantz m...@zentific.com said: you could write a small executable to query/set the mixer props - and that small binary can use glib... ironically, having written a similar CF for eeze mounting, I didn't think of this. now... if there is an api to swizzle with PA. there thus MUSt be a protocol it talks to PA. this protocol must obviously then exist in some form (be it a plain socket, a dbus api, etc.) so.. my guess is you missed something? from what I could tell, it does something funky with the permissions of the socket that it connects to. the code is also pretty heavily obfuscated. I'll look at it again and maybe try some ecore-con nonsense... heyo, I spent several hours today examining pulseaudio, planning to start hacking on the mixer code. What I discovered is very depressing: * libpulseaudio REQUIRES glib and REQUIRES glib main loop. literally. they're params for pa_context_new(). this is doable, but not at all in the context of our current mixer module. * there is a full dbus api for pulseaudio. luckily, the geniuses working on it aren't releasing it: http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-June/010160.html * I looked into reverse engineering the control protocol by manipulating a socket that PA uses: also a no-go since the tcp protocol must be manually enabled by editing a config file. * pulse has a number of library interfaces to work with. none of these let you manipulate volume mixers. as far as I can see, unless the dbus api comes out tomorrow (PA 1.0) and everyone magically adopts it overnight we should probably drop this item from the 1.0 TODO, and imo permanently unless someone wants to rewrite the whole mixer to function with both: * multiple driver backend support (alsa+pulse+oss+jack+wtfelse) * async driver APIs (such as pulse/jack) support it's been a huge headache learning even this much, so unless someone is more masochistic than me, I strongly suggest marking this WONTFIX. -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- 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-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- 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-d2d-c2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
