1. Discussions & comments
JeffWaugh: Marc-André, why not create plugins for polypaudio to make it GNOME/D-BUS aware? It already has a significant amount of the difficult audio stuff done, and it really doesn't make a lot of sense to start yet another audio server effort. This means that you would be able to spend more time on beautiful integration love, and solving real use cases, than worrying about boring audio mixing details.
Definitely take a look at this: http://0pointer.de/blog/projects/polypaudio-0.9.0.html
MarcAndreLureau: Thank you Jeff for your answer. I have never met polypaudio before, hence I have to investigate a bit further. I feel that you understood the aim of this project is to developp a multi-stream/channel software audio mixer (or a sound server, if we add network support over it). Excuse me if I am wrong to correct this, but my goal is to provide a smart audio effect controller with peer sinks exclusively. The sinks will simply deal with gstreamer features and communicates with dbus. The controller (the term "mixer" leads to some confusion) is not an audio multiplexer. My understanding is that gstreamer is almost able to give the same services as polypaudio: if we chained up network sources (with esnd protocol...) to an audiomixer (The multiplexer) and then to an audio sink (alsa, oss...) and make this pipepline running as a daemon.
I am now wondering if it is more appropriate to control polypaudio (the volume of each incoming audio channel, as "volume meter" does) or gstreamer sinks... I think that the better is to stay close to the application that emits audio to be able to add feedback later to the application (on the volume slider, eg.).
StefanKost: Marc-André, some more comments:
- one important class is 'Alarm', think of calender-alarms, messenger-ringtones. the policy here is to maybe lower the level of background music and mix in the alarm-sounds.
- point out that your project approaches a specific variant of a general ressource-management probelm. Similar problems exist with e.g. video-playback. A gfx card has only a limmited number of xv-ports. When a voip call comes in, one might want to stop video-playback to gain the xv-port for the voip call.
- please clarify the "a UI that control volume .." part.
MarcAndreLureau: Hi stefan!
- Yes, "Alarm" is probably one of the most important class. I think the definition of classes and properties will be written in a configuration file. Don't worry, you will be able to add classes. And some of the basic configuration (priority, application-class membership) will be available on the UI. I keep in mind the simplicity over anything. (kiss)
- It won't be easy to deal with the general problem from scratch. So I want to start with sound management. This is probably the easiest way to start something up. But you are right, we have to remember that the architecture could, one day (I hope), support more ressources than audio output.
DanteMeulemeester: I liked the ui's that were created as mockups for GNOME TOPAZ Suse Linux Enterprise Edition 10 sp1 (according to Rodney Dawes). I have links to some of them i like especially the second one
StefanKost: Marc-André, even more comments:
see http://chabada.sk/better-desktop/#pause-on-mute for another use case of GSmartMix.
Audio team of Vista naked (really nice video close to my inspiration, S. Ball)
http://channel9.msdn.com/ShowPost.aspx?PostID=116347 (general, sept. 2005)
http://channel9.msdn.com/ShowPost.aspx?PostID=215402#215402 (UAA, policy, mockups, role, array capture, HD def., july 2006)
Flat Volume Control & algorithm used (P. Baudish - Microsoft Research)
Thanks Google patents
inspiring, I should get a project name and a logo from these patents
- Indie Volume (the first? per-application Windows volume control app)