(Oops: forgot to Cc the list.)
Dear Tetsuya,
On 2020-03-20, Tetsuya Isaki wrote:
> 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.
No problem at all!
> > > 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.
I will try again to reproduce the problem with a minimal
program. It was not easy to reproduce the ffmpeg problem
(I am not sure why, maybe its is a combined pts calculation
and non-blocking read problem).
> 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.
I am sure the ffmpeg calculation is wrong, but (as you say) changing it
does not fix the problem.
--
Kind regards,
Yorick Hardy
