Sara, > If there is a call established between the 2 end users but they are not speaking , then no new packets to send ?
This is not a question for the GNU Radio mailing list, since this is a characteristic of the soft phone, obviously. > If there is no new packets coming , I want to send zeros instead of repeating the sent packets , How Can I do this ? How and why would you repeat packets? There's no mechanism for that that I would know of. Ok, so to make this as short as possible, here's my deduction on your question: - you don't know the "real world" rate at which packets are generated by your soft phone. If you knew, you wouldn't be asking, because then you would just be padding them to match the over-the-air bit rate [0]. - knowing when to wait for a packet or when to zero-pad would require knowing how much voice duration was carried in one packet AND how much real-world time has passed. Knowing that requires knowing what kind of information these packets carry. My first mail regarding how to deal with RTP packets applies. - you want to transfer packeted data, but you want to construct a continuously streaming transmitter; while this is possible[1], it's certainly not really easy to implement cleanly in GNU Radio and not very intuitive, either. I'd recommend going for bursted transmission using the start-of-burst tag functionality. Greetings, Marcus [0] ... which would be, information-theoretically, a bad thing to do, if the amount of padding was significant: compressing speech (ie. removing redundancy) and transmitting that at a higher bitrate just to add zeros to match the original bit rate is really just reducing your energy per bit. You'll probably get a better transmission if you were to reduce your transmission symbol rate to match your soundcard's sample rate and transmit uncompressed audio, and you would be avoiding all the hassle you're experiencing now. [1] This is usually done when re-synching is expensive. A typical example for these kind of transceivers are wireless optical networks, where the medium is often occupied by a rectangle signal, unless there is a packet on there, which has a preamble. Using GNU Radio, detection of preambled packets has gotten easier, compare the modern gr-digital examples, and clock recovery is, if needed, possible, so there usually is no need to continuously occupy your carrier with zeros. _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
