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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
