-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again!
On 04.12.2013 11:36, Artem Pisarenko wrote: > >> In GNU Radio terminology, since we're more of a library than an >> application, users are people who use GNU Radio to develop their >> own applications. Developers are people who actively work on GNU >> Radio and improve it. >> > I meant user/developer from toolkit use point of view: user - > developer who uses GNU Radio API in its applications and have no > time/budget to delve into innards of huge ready-to-use code only to > know few key concepts, developer - developer of GNU Radio toolkit. Well, unfortunately, this is open source :) some things are easier to do while others take a lot of time. Explaining how something works internally for someone who is actually interested in that but doesn't have the time to read the source itself is among the things that are hard to do well, become obsolete fast, take a lot of time -- so nobody does it. >> You still have two clocks in one flow graph. Underruns can still >> happen. > > Why ??? These clocks are actualy same clock. They are synchronous. No. Well, yes. But no. Again, there is no continous stream in GNU Radio. Samples and especially blocks of samples, as used in GR, are not like water: They flow in chunks, there are buffers to accumulate them. Usually, these buffers should be automatically sized so that two sources with the same, constant sample production rate never run out of buffer. I don't know what's going wrong in your case, but that could happen if the sample delay for one of the sources differs from the others -- all (let's call them s0 and s1) start with sample 0, but at the point in time as s0's sample 0 "propagates" to the block where the two sample flows are mixed together, due to delay there is no sample from s1; so the scheduler has to wait until there is enough input on both input ports of the mixing block. Depending on buffer size and production rate, this might lead to overruns on s0, or underruns on a potential hardware sink behind that block. > Moreover, I'm sure throttle block and audio hardware clock are > synchronous, because throttle block timing and audio driver > scheduling both derive from same hardware generator, doesn't they > ? Moreover, I'm sure you still didn't understand what throttle does: exactly nothing useful. It's an artificial software hack to slow down the average sample processing rate by blocking in work(). YOU NEVER EVER EVER DO IT in a flowgraph with hardware. It can only lead to overflows, underflows. >> Note that not consuming CPU is not necessarily due to blocking. >> An audio sink is quite a simple matter, from a signal processing >> point of view: Incoming samples are passed on to the sound >> driver, then the work function can immediately return (there's >> lots of status checking in there too). > > That's why I already asked what other methods exists besides > blocking. If it doesn't stimulate OS to switch context (by means of > blocking calls), then it consume all available CPU time (it doesn't > matter what kind of activity: signal processing, checking status, > polling hardware flags, or whatever). So, it still seems to be that > audio sink uses blocking. The audio sink has to communicate with audio hardware. However your system does that, the audio driver interface can only consume a defined amount of samples per second and only has a limited buffer size. Therefore, the call that writes samples into the device usually is a blocking one. You see-- this is hardware with a fixed sampling rate, so blocking is an effect, not a method. Greetings, Marcus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSnwmGAAoJEAFxB7BbsDrLrRUH/0uFi17FJjvQWx22wwpiHgQz g+UHppH12GOZddfCnGvHXbm3JBOILYDJ2cScdgLFFNshWZFV1r2z2ko6knvi5FBl MHtjRBTFheyMuONNEetPDNRQZL6KuKrB7EAUuflmJ+D/roZjR6N9aC81mI0qsOVL mSZzmJbXM35mY0OvRDGx82MxpNzM94z7aLRqhiwXKRvMy8VwEwPBLrLgTYXy1MJe A7K++4S8LNROoFAFHY+QQ85EJ2oVb3b1O/r/j4f80YTJ+l9LYDwVqu2yy72XVgpH 9lHvgcTFR59ISUcQRPZDUkVtffPhF6ON+Nz/Dm4jWj22ZbttaHH8U24wTtPJZvk= =FBY0 -----END PGP SIGNATURE----- _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
