[FFmpeg-devel] [PATCH] ALSA for libavdevice

[Michael Niedermayer]

On Mon, Dec 15, 2008 at 12:05:31AM +0100, Nicolas George wrote:
> Le tridi 23 frimaire, an CCXVII, Michael Niedermayer a ?crit?:
> > 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.
> 
> The timestamps from ALSA come in the form seconds+nanoseconds, not in
> samples, and as far as I could see in the kernel driver part, they are in
> that format from the very start, so I am afraid that converting to
> samplerate*128 is more likely to accumulate conversion errors than correct
> them.

you add 2 values, one being nanoseconds, one being samples. The timebase
choosen is a multiple of neither.
Before you add them you round both incorrectly, correct being to the next
closest integer.


> 
> Furthermore, on of the main advantages of time-of-day based timestamps is to
> be able to pass them back to localtime to display the time of recording.
> Converting the timestamps into another unit makes this (a little) harder.

where can any localtime be passed to display?
This localtime isnt ending up in an encoded file, is it? This would be a
security issue


> 
> > can this change the samplerate/codec_id for the recording case?
> > If so how does that work, the code throws the value away afterwards
> 
> The sample rate can be slightly changed depending on the hardware
> capabilities. The codec_id can be changed from NONE to the default one. The
> values are not thrown away afterwards, audio_read_header uses them to set
> st->codec->codec_type and st->codec->sample_rate.
> 

> For playback, on the other hand, if the sample rate is changed, the
> resulting value is discarded. It may be better to fail in that case, or to
> fail if the change is too big or something; I believe it is a matter of
> taste.

please explain me how av sync works if the samplerate is changed and thrown
away?


[...]

> +    /* take real parameters */
> +    st->codec->codec_type = CODEC_TYPE_AUDIO;
> +    st->codec->codec_id = codec_id;
> +    st->codec->sample_rate = sample_rate;
> +    st->codec->channels = ap->channels;
> +

> +    av_log(NULL, AV_LOG_INFO, "sample rate: %d\n", sample_rate);
              ^^^^
NULL is not a good context, besides this line is likely not that usefull

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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- 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/20081215/bafdb59d/attachment.pgp>