GNOME Bugzilla – Bug 607321
improve GstDTMFSrc
Last modified: 2013-04-21 18:25:32 UTC
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.
(In reply to comment #0) > - there should be an example for type=0 as I can't see how one would then > specify the frequencies. Type 0 is not implemented right now (but it exists in the RFCs), that's why there is no example. > - 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. If the application is a gateway or a conference server, yes they could be mixed because the events would really be coming as RTP packets from the other side. > I still wonder what can be done to classify such an element as "special" so > that a normal music application could avoid it. The idea was that you could put dtmfsrc and/or rtpdtmfsrc into a pipeline and just send the even to the pipeline and have the right thing happen. That said, right now, in farsight2, there is custom code to deliver the events to the right element.
For the special classification, maybe we can add something to the klass ?
As another idea, I use write-only properties for triggers in buzztard since a while. Then you don't need an event.
the problem with a property or something is that you have to fish out the source of the pipeline to use it. While with an event, you don't have to know, you can just send an event to it.
True, Now take this :) The advantage of a property is that you see it on gst-inspect. Anyway, was just an idea.
We can add properties also, but I'm afraid the event kind of needs to stay, because Farstream depends on it. Doing doing this with a property is a big annoying, as starting an event has 3 things in it (the method, the volume, the number.. and we could possibly add a duration). So either we need to give the property some kind of structure with all of that, and that becomes quite complicated.
In music synths, on param is the trigger parameter. You would set e.g. method and volume and when you write number, it starts a new tone using the volume and method currently set. In buzztard I would make 'number' write-only to indicate that this is the trigger param.