Alsa "short read" questions

Alsa "short read" questions

[Pierre Vanhoucke]

Hi All,

Is there anybody out there who can help me to answer the following
questions:

I have converted an application called Linrad
( http://www.nitehawk.com/sm5bsz/linuxdsp/linrad.htm ) from OSS to ALSA.
Linrad is a remarkable DSP application used worldwide by many
radio-hams.

I am facing hereby a problem with a "short read" :

An ALSA device is opened in blocking mode:

*********************************************
err=snd_pcm_open(&rx_ad_handle, 
                 rx_sndin_plughw_pcm_name,
                 SND_PCM_STREAM_CAPTURE,
                 0);
*********************************************
When I subsequently read the device with following statement I sometimes
get a "short read":
********************************************
      err=snd_pcm_readi(rx_ad_handle,rxin_isho, rxad.block_frames);
      if((unsigned int)err != rxad.block_frames)
        {
        if(err == -EPIPE)           // EPIPE, try recovery  
          { 
          err= snd_pcm_recover(rx_ad_handle, err, 0);
          if(err < 0)lirerr(1108);  // recovery failed
          }
        else 
          {
          if(err < 0)             
            {
            lirerr(1113);           // catch all
            }
          else
            {
            lirerr(1116);            // short read
            }
          }
        }
      }
**************************************************

Here are my questions:

1. How is it possible to get a "short read" in blocking mode ?
I would think that in blocking mode the control is only returned after
the read is completed.

2. What are the possible causes for a "short read" ?

3. What can be done to  avoid a "short read" ?

4. How am I supposed to recover from a "short read"?


Best regards,

Pierre Vanhoucke/ ON5GN

Re: Alsa "short read" questions

[Clemens Ladisch]

Pierre Vanhoucke wrote:
> 1. How is it possible to get a "short read" in blocking mode ?
> I would think that in blocking mode the control is only returned after
> the read is completed.

When an error occurs, you get the data that was read successfully before
the error.  We wouldn't want to throw away this data just because an
error happened later.  (This behaviour is for consistency with other
uses of read(); in the case of audio, throwing away some data wouldn't
actually hurt that much.)

> 2. What are the possible causes for a "short read" ?

Buffer overrun, USB device or SPDIF source unplugged, other errors.

> 3. What can be done to  avoid a "short read" ?

You cannot prevent the user from unplugging a USB device, or the
administrator from suspending your program until the buffer overruns.

> 4. How am I supposed to recover from a "short read"?

Try to read the rest of that data that you wanted to read originally,
then you'll get the error code.  (Or you'll get some data if the error
has vanished, but that is very unlikely.)


Best regards,
Clemens