At Thu, 19 Mar 2020 21:36:00 +0200, Yorick Hardy wrote: > > > ffmpeg4 -f oss -i /dev/audio -channels 1 -sample_rate 48000 /tmp/test.wav > > > > > > is completely garbled and too short. The file also seems to be 2-channel, > > > so I think the recording settings are somehow not applied correctly. > > > > I rarely use ffmpeg4 but according to ffmpeg4 documents, > > -channels/-sample_rate are for video and -ac/-ar are for audio? > > If I used it correctly, it is for "-f oss" so for the input. Maybe it > should go before "-i", but if I recall correctly it does not make > a difference. > > I think "-ac" is for the output format (ffmpeg performs appropriate > conversion).
I see, sorry for noise. > > As you said, output file was too short. However ffmpeg4 probably > > recorded specified period and created small file so that I think > > you need to look ffmpeg4 at first. > > I did not figure out why the file is too short, but there is some > oss/ffmpeg interaction (maybe due to non-blocking reads?) which causes > this. It's hard to believe that non-blocking read affects. I've implemented non-blocking i/o carefully too. If you find how to reproduce the problem, please send PR. By the way, in ffmpeg-4.2.1/libavdevice/oss_dec.c: 70 static int audio_read_packet(AVFormatContext *s1, AVPacket *pkt) 71 { : 95 /* subtract time represented by the number of bytes in the audio fif 96 cur_time -= (bdelay * 1000000LL) / (s->sample_rate * s->channels); I wonder why this calculation doesn't have precision (16bits = 2bytes). I modified this line but it did not seem to improve. But I didn't chase more. Thanks, --- Tetsuya Isaki <is...@pastel-flower.jp / is...@netbsd.org>