On 06/22/12 00:54, Clemens Ladisch wrote: > Bryan Ischo wrote: >> Hm, I think I may have found the reason that it doesn't work sometimes >> ... I just printed out the boundary value that I am getting from >> snd_pcm_sw_params_get_boundary(), and it is 4611686018427387904 (on a 64 >> bit system where sizeof(snd_pcm_uframes_t) == 8). >> >> That value is 0x4000000000000000 in hex. I have no idea what that means. > There's nothing wrong with this value. The boundary value means something > similar to "infinity", and to make some computations easier, it's made > a multiple of the buffer size. > > Thank you for your response. I don't understand why a bounday value of 'infinity' is being reported though. The ALSA documentation doesn't mention that it is possible for the boundary to be reported as 'infinity', or how to detect that this is what is being reported (what is the largest non-infinity number that could be reported for a boundary?). 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. Surely this value is knowable and reportable - why is ALSA reporting 'infinity'? My goal was to try to produce an underrun-proof playback mechanism - I just want silence to be played if I haven't supplied any audio data. To me this is very logical; I don't really understand why all audio pipelines aren't underrun-proof already by just playing silence when there is no audio data to be played. The only thing I can think of is that when audio data does become available, you often want to play it with the lowest latency possible, and if the driver is busy playing silence you may have some delay before your audio data can be appended to the audio stream (i.e. there may be some silence frames already delivered to the hardware that you can't "take back" so your audio has to wait a little bit before it can be played). In this case I can see there being some reason for an audio pipeline that allows underruns - it's a way of saying, rather than play silence, just stop playing and be as ready as you can be to play audio as soon as I can provide it to you. The thing is - there is a latency cost is re-starting the audio pipeline after underrun isn't there? You have to call snd_pcm_prepare again, and that seems like it costs something. Is the cost of doing snd_pcm_prepare() greater latency or less latency than if the driver were busy playing some silence frames instead of underrunning and your audio data had to wait for that? Let me ask more succinctly - why do audio pipelines allow underrun? What is the benefit over just feeding silence to the hardware until more audio data is available? 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
