I repeat myself...use 'paplay' or 'aplay' and the result is fine. On Sun, Aug 29, 2021 at 6:31 PM guest271314 <guest271...@gmail.com> wrote:
> How do we know what the expected result is? > > On Sun, Aug 29, 2021 at 5:01 AM mindfsck <mindf...@gmail.com> wrote: > >> you could try is making use of the buffering attributes in >>> pa_simple_new. Specifically, setting prebuf to a suitable value. >>> >> >> I tried setting prebuf to -1, 0, 1, 2, 4, 16, and 320. Made no difference >> to me. >> >> Another thing to check is if there are a couple of silent samples at the >>> beginning of the problematic wav files >>> >> >> I checked. The first 20ms are silent samples. >> Attached is the file. >> >> On Sun, Aug 29, 2021 at 12:06 AM Sean Greenslade <s...@seangreenslade.com> >> wrote: >> >>> On Fri, Aug 27, 2021 at 04:57:07PM +0200, mindfsck wrote: >>> > I seem to be to silly for it: >>> > # sox in.wav -r 22050 out.wav resample >>> > sox FAIL formats: can't open input file `out.wav': No such file or >>> directory >>> > >>> > Of course there is no out.wav since that's what I want to create! >>> >>> I would not bother with trying to change sample rates, that's very >>> unlikely to be the issue. Plus, a lot of sound cards only support 44.1 >>> kHz and 48 kHz, so pulse would just have to resample it again on >>> playback. >>> >>> One thing you could try is making use of the buffering attributes in >>> pa_simple_new. Specifically, setting prebuf to a suitable value. There's >>> some helpful info in the buffer_attr docs page here: >>> >>> >>> https://www.freedesktop.org/software/pulseaudio/doxygen/structpa__buffer__attr.html >>> >>> Another thing to check is if there are a couple of silent samples at the >>> beginning of the problematic wav files. If the first sample is non-zero, >>> that could potentially cause pops on playback. >>> >>> --Sean >>> >>>
