chan_usbradio: soundcard_writeframe - write buffer overflow

[KB4MDD]

I have noticed that I am now seeing chan_usbradio's soundcard_writeframe report the following message:

chan_usbradio.c:1431 soundcard_writeframe: Channel usb_53812: Sound device write buffer overflow - used 6 blocks

I don't recall seeing this message in the past. The default queue size is 2 blocks. I tried increasing to 6, but I still see the error.

This is occurring on a raspberry pi 4 system. I have another raspberry pi 4 system running an older code that does not report this problem.

This message generally happens when there is no activity on the repeater.

I am filing this issue as a reminder to review the code changes. This could be device specific.

This same routine is used in chan_simpleusb and I am not seeing that issue on two other installs (they however are not raspberry pi).

[KB4MDD]

I believe this is really an old problem that is just coming to light due to the recent logging changes. The original code only reported the error when debugging was enabled.

    if (res > o->queuesize) {   /* no room to write a block */
        // ast_log(LOG_WARNING, "sound device write buffer overflow\n");
        if (o->w_errors++ == 0 && (usbradio_debug & 0x4))
            ast_log(LOG_WARNING, "write: used %d blocks (%d)\n", res, o->w_errors);
        return 0;
    }

I will recommend changes after further research and monitoring my systems.

This comment in the code could give an indication to the nature of the problem.

    //  maw maw sph !!! may or may not be a good thing
    //  drop the frame if not transmitting, this keeps from gradually
    //  filling the buffer when asterisk clock > usb sound clock
    if(!o->pmrChan->txPttIn && !o->pmrChan->txPttOut)
    {
        //return 0;
    }

I have noticed that increasing the queue size in usbradio.conf causes the system to take longer to report the problem. I may uncomment the return statement and see if there is any adverse operation. I really don't know that there is a need to output packets to the sounds card if it not actually transmitting.

[tsawyer]

At one time there was a theory of continuous output to the sound card would improve response. Only difference I noticed is that the green LED would blink continuously.

[KB4MDD]

Further research reveals:

With modern processors and a good OS scheduler like the Linux one setting the fragment size to anything other than half the buffer size does not make sense.

We are using a fragment size larger than our buffer. I will be testing other values.