-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Sylvain,
Ok, I see the point here and I agree that it would be nice if a block was notified of a "filling output buffer chain" in advance. (you could, however, use the noutput_items parameter or nitems_written() together with some system clock to get an idea of what is being consumed) However, you explained the problem very nicely: Your hardware does something strange, e.g. repeating samples, when it goes too slow/fast. The only way to actually account for that is the monitoring of the sink sampling clocks relative to the source sampling clock. However, that's something you can't do in software, you need some hardware feedback to give you a reasonably exact estimate of the frequency offset, since you don't see the output of your hardware sink (usually). For different soundcards there might (and might not) exist some method to find out how fast a playback buffer got used up; this is very hardware-dependent and not easily unified in software, especially since in this case timing offsets in the order of microseconds are relevant and if your feedback mechanism incorporates context switches, async messaging and computation, you won't be getting reliable results. Basically: If your hardware is "bad" by means of drifting/wrong clocks, and you can't monitor your output, you'll be having a bad day. This is an inherent problem of SDR, I reckon, and from my point of view the only solution would be constraining hardware clocks of sinks and sources using a common master clock (that's what most SDR peripherals do, therefore), or monitoring the sink output using the same source clock (which is just another incarnation of controlling the sink clock using the source clock). In software architectures like GR that rely on "large" buffers to enable normal operating systems to run the SDR, I guess you will have a hard time figuring out actual clock deviations just by measuring buffer filling; there's just so much more than just the sink clock going astray that could happen which will make things look like latency was building up. Again: Using GR you usually try to ignore the fact that computation may (and will) take different amounts of time at different points in time, even for the same block, and rely on the scheduler to call the linked blocks' work()s with fitting parameters. Measuring the amount of data that passes through software buffers won't therefore help you much when measuring the sampling speed of a hardware sink, or only on very large time scales. Greetings, Marcus On 13.12.2013 11:48, Sylvain Munaut wrote: > Hi, > > >> Blocks shouldn't care for their own buffer "fill"; that's the job >> of the runtime and GR does this fairly well, to be honest. Your >> Virtual machine audio related problem is hardly a proof of >> shortcomings of this concept. > > I don't agree with this. > > Blocks should be able to monitor the buffer level to act in > consequence. > > A real world example : - RF front end gets samples - Demod process > to compressed audio frames - Sends to codec to convert to audio - > Sends to audio card for playback > > Now in this system you have two physical unrelated clock source; > The RF sampler and your audio card. All the samplerate relationship > in the flow graph would be adjusted for their nominal speed but of > course they won't be in perfect sync. > > Now if your audio card is a bit faster, it will run out of samples > from time to time. It might replay automatically the last one and > you might not hear it. But if your audio card is a bit slow, the > buffer in front of it will slowly fill up and you'll have a rising > latency (and finally drop samples when it fills up). > > Now a real world vocoder I'm working with right now deals with > this problem by having variable length audio frames. When I get one > frame of encoded audio, I can ask the codec to generate between > 19.5 ms to 20.5 ms of audio (for a nominal 20ms frame) and it's of > course much better than dropping/repeating samples blindly. > > But to be able to use this, the codec block needs to be able to > monitor the output buffer level so it can try to maintain it at a > good level. > > > Cheers, > > Sylvain > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSqvhOAAoJEAFxB7BbsDrLTvQH+wQi8ayhT5H4pXCTjxMgHkZR gSvbZAW6eZ5TLl0RSDyWtdyXwjSlNiH669r1q8i7zaq6H32395SjwkYYPyuAumRU N4qFS76AcvZLcCCuzuvC6fPFlbu2RTFtGINC9Buy9K2W2jwiOWLMYwKJ6Idenl8t vjKB83Epn/vue3iIclvyijgMm6uF0M/+SUS8AFe2SAmPwKc3tHZquwnodiPTIE+q sLykZfcirU8Ws9ibb3tReRW5pEi8b8Lt5rLJHtLJmUouiyqWcvpghypUy5MIbGin pTlxH8eFVaqPqANC+vwEzV6lOjDz11i7YRAUDwq7Ex7U4YVXqU46/tLL95LA9r0= =j4Q3 -----END PGP SIGNATURE----- _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
