On 06/26/12 11:03, Bryan Ischo wrote: > On 06/26/12 10:15, Bryan Ischo wrote: >> >> 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. > > To be clearer: the above works until the first time that there would > have been an underrun (i.e. silence is played out instead of an > underrun), after which only silence is ever played. > > If I disable the above in my implementation, then I get an underrun > and have to re-prepare the pcm. If I enable the above, at the moment > that I would have gotten the underrun, instead I get silence forever > thereafter. After some research, I have found various discussions previously on various mailing lists over the years about a desire to have ALSA be able to play silence instead of underrunning; universally the desire is always to be able to have ALSA immediately start playing any audio data written instead of having to suck in enough data to "catch up" to where the hardware play position within the ring buffer is. If I understand fully, ALSA's write position within the ring buffer does not move forward unless data is presented, and there is no way to tell ALSA to move the write position to match the hardware read position within the ring buffer when these two get out of sync. Thus when trying to play silence instead of underrun, once the would-have-been-underrun event occurs, the application write position within the ring buffer becomes stranded and is never again able to re-sync with the hardware read position, unless the PCM device is reset, which leads to the same audio pops that would have occurred had underrun been allowed in the first place, defeating the entire purpose of silence-instead-of-underrun. So what I need is a way to tell ALSA to re-sync the application write position with the hardware read position without having to reset the device. Before I start digging into the ALSA code to understand this better, is there any obvious way to make this happen with the current APIs? What about if I use ALSA mmap mode and manage pointers myself? Is it possible then? 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
