Re: Audio recording (using ossaudio)

[Yorick Hardy <yorickhardy%gmail.com@localhost>]

(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