docs/design/draft-klass.txt: Add example that needs more thinking.

Original commit message from CVS:
* docs/design/draft-klass.txt:
Add example that needs more thinking.
* docs/design/draft-missing-plugins.txt:
More thoughts about wtrapper plugins.
* docs/random/ensonic/embedded.txt:
* docs/random/ensonic/profiling.txt:
More design work.

ChangeLog

@@ -1,3 +1,15 @@
+2007-03-28  Stefan Kost  <ensonic@users.sf.net>
+
+	* docs/design/draft-klass.txt:
+	  Add example that needs more thinking.
+	
+	* docs/design/draft-missing-plugins.txt:
+	  More thoughts about wtrapper plugins.
+	
+	* docs/random/ensonic/embedded.txt:
+	* docs/random/ensonic/profiling.txt:
+	  More design work.
+
 2007-03-25  Wim Taymans  <wim@fluendo.com>
 
 	* libs/gst/base/gstbasesrc.c: (gst_base_src_get_range),

common

@@ -1 +1 @@
-Subproject commit dec151d15512e4cca2dcdd36d9c6c4a2185760ec
+Subproject commit 57d4a1587556bd42c850601773c662211694c5a6

docs/design/draft-klass.txt

@@ -149,6 +149,12 @@ Proposal:
      level            : Filter/Analyzer/Audio
      tee              : Connector/Debug
 
+   5) open issues:
+
+     - how to differencial physical devices from logical ones?
+       autoaudiosink    : Sink/Audio/Device
+       alsasink         : Sink/Audio/Device
+
 Use cases:
 
   - get a list of all elements implementing a video effect (pitivi):

docs/design/draft-missing-plugins.txt

@@ -250,6 +250,12 @@ A three step process:
    jokosher or pitivi start requestion elements by name, for example ladspa
    effect elements or so.
    
+   This case could be handled if those wrapper plugins would also provide a
+   gst-install-xxx-plugins-helper, where xxx={ladspa|visual|...}. Thus if the
+   distro specific gst-install-plugins-helper can't resolve a request for e.g.
+   element-bml-sonicverb it can forward the request to 
+   gst-install-bml-plugins-helper (bml is the buzz machine loader).
+
 
 7) Further references:
 

docs/random/ensonic/embedded.txt

@@ -25,10 +25,33 @@ Elements with higher rank should be functionaly more complete. If we have
 multiple elements that are feature complete there is a draw.
 
 There are more decission criteria thinkable:
+* target processor (CPU,DSP,GPU)
 * ressource usage (CPU, memory)
 * license (proprietary, open source)
 * quality (in terms of the audio/image quality)
 
 One problem of taking criteria like quality and performance into account when
-autoplugging, is that elemnts might have options to control them.
+autoplugging, is that elements might have objects-properties that influence
+them.
 
+Beside adding more ranking criteria, we might consider adding an overridable
+mechanism for picking elements (basically registry filters that not decide on
+the base of ranks). Applications might choose the filter mechanism based on the
+use-case (which gstreamer not know right now).
+
+== g_malloc vs. g_try_malloc ==
+g_malloc/g_new should not be used when allocating space of a size that is
+derived from a value found in the file. Instead one should use g_try_malloc or
+g_try_new and check the return value.
+
+$ find . -name "*.c" -exec grep "g_malloc" {} \; | wc -l
+190
+$ find . -name "*.c" -exec grep "g_try_malloc" {} \; | wc -l
+0
+$ find . -name "*.c" -exec grep "g_new" {} \; | wc -l
+398
+$ find . -name "*.c" -exec grep "g_try_new" {} \; | wc -l
+3
+
+This is not strickly related to embedded, but its easier to crash gstreamer on
+embedded this way.

docs/random/ensonic/profiling.txt

@@ -14,22 +14,17 @@ $Id$
 = qos profiling =
 
 * what data is needed ?
-  * streamtime,propotion pairs from sinks
+  * (streamtime,propotion) pairs from sinks
     draw a graph with gnuplot or similar
   * number of frames in total
   * number of frames dropped from each element that support QOS
     elements that don't support QOS wont have this information anyway
+  * needs to be media type specific:
+    * video: full frames
+    * audio: partial buffers can be dropped in the sink, count number of dropped
+      audio frames
 
-* idea1: parse data from debug log
-   GST_QOS gstbasesink.c:1188:gst_base_sink_send_qos:<xvimagesink0> qos: proportion: 0.895615, diff -16437500, timestamp 0:00:09.208333333
-  basesink gstbasesink.c:1542:gst_base_sink_render_object:<xvimagesink0> buffer late, dropping
-  basesink gstbasesink.c:2534:gst_base_sink_change_state:<alsasink0> rendered: 1028, dropped: 0
-   basesink gstbasesink.c:2534:gst_base_sink_change_state:<xvimagesink0> rendered: 598, dropped: 10
-
-  + easy to do
-  - debug log changes timing
-
-* idea2: query data (via gst-launch)
+* idea2: query data (e.g. via. gst-launch)
   * add -r, --report option to gst-launch
   * send duration to get total number of frames (GST_FORMAT_DEFAULT for video is frames)
   * during playing we need to capture QOS-events to record 'streamtime,proportion' pairs