Sorry for the spam, Fixing: occurring some audio underrun..
2014-08-06 11:23 GMT-03:00 Douglas Amorim Ferreira <[email protected]>: > Well, > > I have a signal and I want to get some information from it. > I want to create demodulators and filters at runtime, and so they are no > longer needed, remove them (and freeing any resources associated with them > ). > I'm having problems with an example that I am implementing. > > Initially I have two blocks connected: > > Audio source ----> Audio sink > At runtime I'm adding new branches: > > Audio source ----> Audio sink > |---> Some block ----> Null sink > |---> Some block ----> Null sink > . > . > |---> Some block ----> Null sink > > After adding 100 new branches, I remove all of them returning the initial > topology. (Audio source ----> Audio sink) > > These additions and removals occur cyclically.. > > The strange thing is that after a few cycles, the audio starts to get > delayed (occurring some audio underflow). > > My big question is: this audio delay is related to the creation and > removal of blocks or not? > > Any suggestion? > > > Thanks again, and again! > > > 2014-08-06 10:16 GMT-03:00 Marcus Müller <[email protected]>: > > I think Sylvain put his finger on a slightly painful place here: >> I think you might not be very clear about the idea what "destruction of >> a block" actually means. >> So, the most interesting question here is: >> Why would you manually want to destroy a block? >> >> Greetings, >> Marcus >> >> On 06.08.2014 15:02, Sylvain Munaut wrote: >> >> The creation and destruction of blocks at runtime must be made between >> >> lock() and unlock(). Is it right? >> >> How can I destroy a block at runtime? block->stop()? >> >> Do I also need a reset() in sptr [block.reset()]? >> > >> > Well, you never really destroy blocks yourself since all you get is >> sptr. >> > >> > So once it's disconnected and you "loose" the last sptr you have to >> > it, then it should get deleted. >> > >> > Cheers, >> > >> > Sylvain >> > >> > _______________________________________________ >> > Discuss-gnuradio mailing list >> > [email protected] >> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > > -- > *Douglas Amorim Ferreira* > -- *Douglas Amorim Ferreira*
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
