Jump to content

Phonon: Difference between revisions

From KDE Community Wiki
move stuff, things get done
No edit summary
Line 1: Line 1:
== Standing Issues ==
=== Effects API returning random identifier namers ==
Amarok finds an Equalizer by looking at the names of the available effects, for xine that would be KEqualizer (which is what Amarok looks for), Gstreamer however uses completely different names...
2 Approaches suggested:
1. Introduce categories - does not resolve original problem, since a consumer still needs a way to differ between devices, introduces additional complexity
2. Fixed Enum - not very dynamic WRT additional magic supported by specific backends. The capabilities would just return enum values and the consumer then issues creation of e.g. Phonon::Effect::Equalizer
=== Apps switching on backend switch ===
This issue is difficult to describe since it has multiple incarnations. The most occurring one is that at backend switch we can only partially destruct the path, leaving it in an inconsistent state from our POV and implicitly depend on the backend to nuke all nodes (only xine does that). In general the whole backend switching business is difficult to support because at every point in time different parts are (or needed) to be responsible for path deconstruction leading to multiple issues.
In an IRC discussion it was concluded that the backend switching is not a terribly important usecase and that we will stop supporting it.
* The KCM's part for switching needs to be moved to an own KCM that is not listed in systemettings
* Switching will only take effect on app restart, the KCM needs to tell the user about this
==TODO==
==TODO==
     * API to allow applications to implement their own effects (independent from the backend)
     * API to allow applications to implement their own effects (independent from the backend)

Revision as of 19:37, 9 December 2010

Standing Issues

= Effects API returning random identifier namers

Amarok finds an Equalizer by looking at the names of the available effects, for xine that would be KEqualizer (which is what Amarok looks for), Gstreamer however uses completely different names...

2 Approaches suggested:

1. Introduce categories - does not resolve original problem, since a consumer still needs a way to differ between devices, introduces additional complexity

2. Fixed Enum - not very dynamic WRT additional magic supported by specific backends. The capabilities would just return enum values and the consumer then issues creation of e.g. Phonon::Effect::Equalizer

Apps switching on backend switch

This issue is difficult to describe since it has multiple incarnations. The most occurring one is that at backend switch we can only partially destruct the path, leaving it in an inconsistent state from our POV and implicitly depend on the backend to nuke all nodes (only xine does that). In general the whole backend switching business is difficult to support because at every point in time different parts are (or needed) to be responsible for path deconstruction leading to multiple issues.

In an IRC discussion it was concluded that the backend switching is not a terribly important usecase and that we will stop supporting it.

  • The KCM's part for switching needs to be moved to an own KCM that is not listed in systemettings
  • Switching will only take effect on app restart, the KCM needs to tell the user about this

TODO

   * API to allow applications to implement their own effects (independent from the backend)
   * encoding to files (or any QIODevice)
   * Hardware Mixer API
   * kded module to handle tasks like:
         o react on plugged new (never seen before) media device
         o manage software volume controls
         o implement policy like muting/lowering volume of selected applications/categories depending on special events (e.g. incoming call)

Done as GSoCs

   * High level capture API 
   * Low level PCM I/O