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