[Libav-user] setting raw alsa pkt size

[daggs]

Greetings Carl,

> Sent: Wednesday, May 13, 2015 at 11:46 AM
> From: "Carl Eugen Hoyos" <cehoyos at ag.or.at>
> To: libav-user at ffmpeg.org
> Subject: Re: [Libav-user] setting raw alsa pkt size
>
> daggs <daggs at ...> writes:
> 
> > as a design decision I've decided to split the grab 
> > and encode to two different threads. each input 
> > (e.g. video and audio) has it's own set of threads.
> 
> Which means that A/V sync is impossible to keep, or 
> do I miss something? (Note that it isn't easy with 
> alsa and xcb in any case.)
> 
well I think it is doable as I've found a project named tp-screencasting-teaching-system which allows broadcasting a lesson over the net.

> > but for audio I get a whopping 939834256 which 
> > translates into 939 mb which is unacceptable for me.
> 
> 939MB per hour? Or per day?
> This is the maximum alsa buffer size on your system.
> 
> FFmpeg uses the maximum possible alsa buffer size to 
> make sure no audio gets lost. There is a TODO in 
> libavdevice/alsa.c on implementing custom buffer 
> size, consider sending a patch.
> 
939MB per AVFrame.

> > looking at the code I see that the default codec 
> > format is AV_CODEC_ID_PCM_S16LE.
> 
> Which is the codec with the second smallest bandwidth 
> amount. (But changing the codec probably wouldn't 
> change the buffer size, or does it?)
> 
not sure, that is why I've asked.

> > I was wondering if here is a way to reduce raw 
> > capture audio frame size to more reasonable amount?
> 
> If you reduce the buffer too much, you will probably 
> miss audio from time to time.
> 
I've assumed that but I'm failing to see how it is possible that a single raw audio frame will require so much space.