Re: SALSA-Lib: Playback overrun on initial PCM start

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At Thu, 28 Jun 2007 15:01:08 -0400,
J. Scott Merritt wrote:
> 
> Dear List,
> 
> Using SALSA-Lib 0.0.3, I call:	
> 
> snd_pcm_open (&playback_handle, argv[1], SND_PCM_STREAM_PLAYBACK, 0);
> snd_pcm_hw_params_malloc (&hw_params);
> snd_pcm_hw_params_any (playback_handle, hw_params);
> snd_pcm_hw_params_set_access (playback_handle, hw_params, SND_PCM_ACCESS_RW_INTERLEAVED);
> snd_pcm_hw_params_set_format (playback_handle, hw_params, SND_PCM_FORMAT_S16_LE));
> snd_pcm_hw_params_set_rate_near (playback_handle, hw_params, 44100, 0);
> snd_pcm_hw_params_set_channels (playback_handle, hw_params, 2);
> snd_pcm_hw_params_set_buffer_size_last (playback_handle, hw_params, &bfrsize);
> snd_pcm_hw_params_get_buffer_size (hw_params, &bfrsize);
> snd_pcm_hw_params (playback_handle, hw_params);
> snd_pcm_hw_params_free (hw_params);
> 	
> snd_pcm_sw_params_malloc (&sw_params);
> snd_pcm_sw_params_current (playback_handle, sw_params);
> snd_pcm_sw_params_set_avail_min (playback_handle, sw_params, 4096);
> snd_pcm_sw_params_set_start_threshold (playback_handle, sw_params, 10000U);
> snd_pcm_sw_params_set_xfer_align (playback_handle, sw_params, 1);
> snd_pcm_sw_params (playback_handle, sw_params);
> 	
> state = snd_pcm_state (playback_handle);
> frames_to_deliver = snd_pcm_avail_update (playback_handle);
> 
> while ((frames_to_deliver = snd_pcm_avail_update (playback_handle)) > 4096) {
>    snd_pcm_writei (playback_handle, &buf, 4096) }
> 
> 
> As soon as the buffer start threshold is reached, or alternatively
> if I manually start PCM stream, the PCM stream reports an overrun
> (i.e. "Broken Pipe").  If I then examine the PCM state, it is in the
> overrun (XRUN) state.

What are the buffer and period sizes?  Did you try alsa-lib with hw,
too, right?

> The code is being cross-compiled and tested on an ARM processor
> (PXA270) which is running linux kernel 2.6.21.   This same code sequence
> -does- operate properly (in the same ARM test environment) when compiled
> against AlsaLib 1.0.13.

Well, it might not be a bug.  SALSA-lib is more straightforward
communication to the driver, and skips many layers.  Thus it may
behave differently.

> Another apparent (and perhaps relevent) difference between AlsaLib and
> SALSA-Lib is that if I open the PCM stream with O_NONBLOCK and then call
> snd_pcm_poll_descriptors, AlsaLib gives me a FD = 4, whereas SALSA-Lib
> reports an FD = 3;

Ditto.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux