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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110501/da7986f0/attachment.htm>
