Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Audio recording (using ossaudio)



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 <isaki%pastel-flower.jp@localhost / isaki%NetBSD.org@localhost>


Home | Main Index | Thread Index | Old Index