Hi Kevin & Marcus, thank you for your answers. After a while of testing I've got interesting results. Firstly, even though it brought 100% CPU load on one core, the packet encoder is not a problem as the underruns also occured without it. Anyway, thank you for your suggestion, I'll certainly look into it. Do you have a link for a thread or something like that where Felix Wunsch mentioned this? And your example: Does that mean I could use this method on on one frequency alone?
Secondly, I had about 25% CPU load on all cores for the first flowgraph, except for when I got these underruns where my CPU load promptly exploded to 100%. However, I'd blame this rise on the underruns themselves as everything was fine shortly before (maybe because of busy waiting?). Nevertheless I've splitted the resampler and I am now using 4 resamplers in a row to get a interpolation of ~100. Both the Socket PDU and the File Source are producing only occasionally underruns but apart from this they are doing fine now. Unfortunately the TunSource block is still producing lots of them (although it's less frequently now). Here's the code for the TunSource. Maybe you can see what's wrong. def work(self, input_items, output_items): out = output_items[0] # Read from tun device packet = tun.read() tun.printPkg(packet) # Extract the header header = packet[:20] unpacked = unpack('!BBHHHBBH4s4s',header) size = unpacked[4] buf = packet[32:] # cast buffer to (iterable) list myarray = list(buf) # Counter variable for position in output array j = 0 for i in myarray: num = 0 try: num = (numpy.int8(ord(i))) except ValueError: num = chr(0) output_items[0][j] = num j = j+1 return len(buf) Regards Paul -- View this message in context: http://gnuradio.4.n7.nabble.com/Audio-underrun-when-using-Audio-Sink-tp60547p60568.html Sent from the GnuRadio mailing list archive at Nabble.com. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio