[alsa-devel] Alsa "short read" questions
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
Pierre Vanhoucke wrote:
- 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.)
- What are the possible causes for a "short read" ?
Buffer overrun, USB device or SPDIF source unplugged, other errors.
- 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.
- 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
participants (2)
-
Clemens Ladisch
-
Pierre Vanhoucke