On 06/23/12 05:59, Clemens Ladisch wrote: > Bryan Ischo wrote: >> Maybe I don't understand what the boundary is supposed to represent; >> I thought it was supposed to represent the largest number of audio >> frames that could be buffered for playback by the driver. > That would be the buffer size. > > The boundary has no meaning in applications; you just use it as > a special value for the stop threshold to disable underruns. >> why do audio pipelines allow underrun? > Because inserting silent samples because without reporting it to the > application would be worse in many cases; any synchronization with other > real-time events would be lost. > > When you don't care, disable underruns. This isn't the default for > historical reasons. > My apologies for my ignorance about sound pipelines, but how is synchronization better maintained with underrun than with playing silence? Of course I would assume that the driver would present an API that would allow the application to say "play these audio frames NOW", and the driver would know how to do that with the lowest latency possible, overwriting whatever audio data bad been previously buffered if necessary (including any silence that was written ahead). I ask because I would like to set up ALSA to behave in this manner if possible. I believe that I can do so with something like: snd_pcm_sw_params_get_boundary(sw_params, &boundary); // Never underrun; allow the sound card to just keep playing whatever is in the ring // buffer, including re-playing old audio if new audio is not available snd_pcm_sw_params_set_stop_threshold(pcmM, sw_params, boundary); // Tell ALSA to zero out just-played audio in the ring buffer, which means that if the // sound card does loop in the ring buffer into an area that doesn't have new sound // data yet (i.e. we weren't able to deliver real-time audio fast enough), silence will // result instead of repeated audio. snd_pcm_sw_params_set_silence_size(pcmM, sw_params, boundary); // The ALSA docs say that silence_threshold has to be set this way if silence_size is // set to boundary snd_pcm_sw_params_set_silence_threshold(pcmM, sw_params, 0); The problem is, the above doesn't work. It just results in infinite silence no matter what sound I try to write into the buffer. What ALSA needs to do is to keep track of whether the next block of audio data that the sound card will read out is valid audio data or overwritten silence; and on snd_pcm_writei() it needs to re-overwrite the silence with the audio data, or append the audio data to the end of the valid audio, depending on whether or not the sound card is next going to read out overwritten silence, or real audio. The goal being to make snd_pcm_writei() append audio data to not-yet-played audio data, or with the lowest latency possible immedately start playing the audio data if there is no audio data being played (because silence is currently being played). Does ALSA do that? Thanks, Bryan ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
