[gstreamer-bugs] [Bug 607321] New: improve GstDTMFSrc
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Mon Jan 18 08:00:35 PST 2010
https://bugzilla.gnome.org/show_bug.cgi?id=607321
GStreamer | gst-plugins-bad | unspecified
Summary: improve GstDTMFSrc
Classification: Desktop
Product: GStreamer
Version: unspecified
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: gst-plugins-bad
AssignedTo: gstreamer-bugs at lists.sourceforge.net
ReportedBy: ensonic at sonicpulse.de
QAContact: gstreamer-bugs at lists.sourceforge.net
GNOME target: ---
GNOME version: ---
GstDTMFSrc uses a custom event to trigger and stop tones. The event is supposed
to be sent from the app. Some comments:
- the docs for description is confusing
"to report a DTMF event" -> "to start or stop a DTMF tone".
As discussed on IRC "the usecase is that one types numbers on a keypad at
arbitrary speed and the app just pushes the events to the source which then
renders the tones according to the standard and the interval settings". So that
could be added to the docs.
- the documentation for the event is a bit confusing.
- method: "2" or absent
Can't you give that a better name and make it a boolean,
or an enum if there are future modes
- there should be an example for type=0 as I can't see how one would then
specify the frequencies.
- would applications mix type=0 and type=1 wildly? What about making this a
property? One can still change the property at runtime. This would make the
events lighter. Same for the volume.
I still wonder what can be done to classify such an element as "special" so
that a normal music application could avoid it.
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the Gstreamer-bugs
mailing list