Also, if i revert to pulseaudio 0.9.14, i do not see this issue happening. I can hear the very short samples in the beginning fine. On Sun, May 1, 2011 at 8:45 PM, Baek Chang <baeksan at ccrma.stanford.edu>wrote: > I am hearing that very very short sounds, smaller than hw buffer size, > occasionally not heard. The initial portion of audio is silenced. If i > remove the rewind request from protocal-native.c, then the problem is > resolved, but other issues are there, audible glitches when doing volume > changes. > > > On Sun, May 1, 2011 at 12:22 AM, Tanu Kaskinen <tanuk at iki.fi> wrote: > >> On Sat, 2011-04-30 at 15:38 -0700, Baek Chang wrote: >> > Hi, >> > >> > I'm seeing some issue with underruns/rewinds occurring on the beginning >> of >> > every sink input playback. >> > I see rewind requests on alsa sink of 9600 bytes. The alsa driver is >> > configured with the following buffer sizes >> > >> > I: sink.c: device.buffering.buffer_size = "9600" >> > I: sink.c: device.buffering.fragment_size = "4800" >> > >> > So it seems like one buffer size is always being rewinded on the >> beginning >> > of playback. >> > Is there a way to prevent these rewinds/underruns when starting >> playback? >> >> Not to my knowledge, except by changing the code. >> >> > after the stream has started, there is no issue with audio dropouts or >> > underruns, just on the beginning. >> > >> > If i log the data that gets sent to alsa, from pulseaudio or in the alsa >> > driver, i do see the beginning being dropped as well. >> > >> > please see attached logs using both tshed=0 and tsched=1. >> > >> > any help with this? >> > thanks! >> >> Are there any real problems with this rewinding, like the beginning of >> the stream disappearing, or an audible drop-out in the audio? The sink >> buffer has to be always rewound when a new stream is created, because >> initially the sink buffer contains silence. That silence has to be >> overwritten with the stream data, so that there's no unnecessary latency >> due to waiting for the silence to be played. >> >> That said, the underrun seems strange, because it happens after the >> "Requesting rewind due to end of underrun" message. I don't know the >> code well enough to be sure that it indicates any error, though. If the >> messages would be ordered the other way around, then it would make more >> sense: first when the stream is created, the buffer doesn't have any >> data, but when the prebuffering phase ends, then a rewind is requested >> on the sink to allow the stream playback to start immediately. >> >> I don't know if this was helpful at all... >> >> -- >> Tanu >> >> _______________________________________________ >> pulseaudio-discuss mailing list >> pulseaudio-discuss at mail.0pointer.de >> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss >> > > > > -- > -baeksanchang > -- -baeksanchang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110501/97f8f3e9/attachment.htm>
