[FFmpeg-devel] [PATCH] ALSA for libavdevice

[Michael Niedermayer]

On Sat, Dec 13, 2008 at 11:24:30AM +0100, Nicolas George wrote:
> Le tridi 23 frimaire, an CCXVII, Michael Niedermayer a ?crit?:
> > "snd_pcm_close(s->h); return AVERROR(EIO);" could be after a fail:
> 
> Changed.
> 
> > > +        if (ff_alsa_xrun_recover(s1, res) < 0) {
> > > +                av_log(s1, AV_LOG_ERROR, "Alsa read error: %s\n",
> > > +                                   snd_strerror(res));
> > the indention is odd
> 
> Fixed. I also changed the strange indentation of other av_log lines to match
> the indent style.
> 
> > > +    pkt->pts = (int64_t)timestamp.tv_sec * 1000000 + timestamp.tv_nsec / 1000;
> > > +    pkt->pts -= (int64_t)ts_delay * 1000000 / st->codec->sample_rate;
> > i think the timebase should be choosen so that one of these doesnt need to be
> > rounded
> 
> I hesitated while writing this piece of code. I considered the following
> reasons:
> 
> - 64 bits microseconds is a common format: it is the result of av_gettime,
>   and the pts format for oss, v4l[2] and x11grab, and other software use it
>   as well; 64 bits nanoseconds, on the other hand, is barely used anywhere.
> 
> - Microsecond is accurate enough for audio samples, with still a good
>   margin.
> 
> - Nanoseconds require 30 bits, leaving only 33 bits for the seconds, while
>   today's timestamp already requires 31 bits, and operating systems are
>   moving time_t to 64 bits.
> 
> - The least significant digits of the nanosecond timestamp is in practice
>   just noise anyway.
> 
> And therefore I chose microseconds. Do you still believe I should change to
> nanoseconds?

hmm, your arguments are good ...
maybe samplerate*128 could be used though, this would allow exact timestamps
for synthetically generated sound or where the systemclock is locked to the
samplerate, or when things are resampled later but the timebase is left.


[...]
> +int ff_alsa_open(AVFormatContext *ctx, int mode, unsigned int *sample_rate,
> +                 int channels, int *codec_id)
> +{
> +    AlsaData *s = ctx->priv_data;
> +    const char *audio_device;
> +    int res, flags = 0;
> +    snd_pcm_format_t format;
> +    snd_pcm_t *h;
> +    snd_pcm_hw_params_t *hw_params;
> +    snd_pcm_uframes_t buffer_size, period_size;
> +
> +    if (ctx->filename[0] == 0) {
> +        audio_device = "default";
> +    } else {
> +        audio_device = ctx->filename;
> +    }
> +

> +    if (*codec_id == CODEC_ID_NONE)
> +        *codec_id = DEFAULT_CODEC_ID;

[...]
> +    res = snd_pcm_hw_params_set_rate_near(h, hw_params, sample_rate, 0);
> +    if (res < 0) {
> +        av_log(ctx, AV_LOG_ERROR, "cannot set sample rate (%s)\n",
> +               snd_strerror(res));
> +        goto fail;
> +    }

can this change the samplerate/codec_id for the recording case?
If so how does that work, the code throws the value away afterwards


[...]
> +    ret = snd_pcm_sw_params(s->h, sw_params);
> +    snd_pcm_sw_params_free(sw_params);
> +     if (ret < 0) {
> +        av_log(s1, AV_LOG_ERROR, "cannot install ALSA software parameters (%s)\n",
> +               snd_strerror(ret));
> +        goto fail;
> +     }
> +
> +    /* take real parameters */

the indention looks odd

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081213/501071bb/attachment.pgp>