[mythtv] prebuffer audio related?

Steven mythmail at richardstraat.homedns.org
Thu Oct 28 17:13:00 UTC 2004


Op do, 28-10-2004 te 10:41 +0100, schreef Ed Wildgoose:
> > I have a Sony receiver connected with spdif and it says PCM 48 on the 
> > display when playback starts.
> 
> 
> Hmm, this will be an interesting scenario...  I think the ATI chipset 
> must be resampling in hardware, and possibly this is tickling a bug in 
> the driver causing it to report free space incorrectly.
> 
> Basically in myth video is clocked to audio.  So you play the audio and 
> examine the timestamps periodically to see if anything is due to be 
> displayed.  However, if the chipset is converting from 32K to 48K, then 
> it might well mess up from time to time (if it's badly written).
> 
> There is no resampler in Myth (unless you are on a very recent cvs), so 
> this must be happening in the chipset.

I recompiled myth cvs yesterday after I installed alsa-lib1.05

> 
> > I was indeed recording at 32Khz (wich is the default MPEG2 settings I 
> > believe?) so I changed to 48Mhz and now the skips are less frequent 
> > and also less noticable.
> >
> ...
> 
> > Using /dev/dsp Av sync is perfect. Using ALSA:spdif or ALSA:pcm.front 
> > audio is a little behind but no prebuffering pause at all.
> >
> 
> Hang on, you said less noticable and then you said perfect?  Which is it?
> 
Let me rephrase that :
/dev/dev/ the Av sync is perfect between the occasional skips
using native alsa there are no skips but Av sync is off 

> We already discussed why the lag exists.  Hang on a while and I will be 
> implementing custom delays in the audio real soon.
> 
Would make my girlfriend realy happy :-)
> 
> > But playing back the recordings with 32Khz audio in them with mplayer 
> > also gives me PCM 48 on my receivers display but the file plays fine.
> 
> 
> Yes, but mplayer HAS got a resampler built into it.  Can you check to 
> see if it's using it (examine the startup verbose output)
> 
Hmm. PLaying back recordings in mplayer gives me (only audio section
included):
---------------
Checking audio filter chain for 48000Hz/2ch/16bit ->
48000Hz/2ch/16bit...
[libaf] Adding filter dummy
[dummy] Was reinitialized, rate=48000Hz, nch = 2, format = 0x00000001
and bps = 2
AF_pre: af format: 2 bps, 2 ch, 48000 hz, little endian signed int
AF_pre: 48000Hz 2ch Signed 16-bit (Little-Endian)
ao2: 48000 Hz  2 chans  Signed 16-bit (Little-Endian)
audio_setup: using '/dev/dsp' dsp device
audio_setup: using '/dev/mixer' mixer device
audio_setup: using 'pcm' mixer device
audio_setup: sample format: Signed 16-bit (Little-Endian) (requested:
Signed 16-bit (Little-Endian))
audio_setup: using 2 channels (requested: 2)
audio_setup: using 48000 Hz samplerate (requested: 48000)
audio_setup: frags:  16/16  (4096 bytes/frag)  free:  65536
AO: [oss] 48000Hz 2ch Signed 16-bit (Little-Endian) (2 bps)
AO: Description: OSS/ioctl audio output
AO: Author: A'rpi
Building audio filter chain for 48000Hz/2ch/16bit ->
48000Hz/2ch/16bit...
[dummy] Was reinitialized, rate=48000Hz, nch = 2, format = 0x00000001
and bps = 2
[dummy] Was reinitialized, rate=48000Hz, nch = 2, format = 0x00000001
and bps = 2
---------------

Now the weird thing is I get the same result playing back recordings
made when myth was set to record with a 32000 samplerate.
Tried setting 32000 again, made a new recording and mplayer still says
the mpeg has 48000 samplerate. Looks like the ivtv driver isn't using
that setting. Can anyone confirm this?

Anyway. It looks like even without resampling going on something is
wrong using /dev/dsp

> By the way, I might have missed something important here.  Does this 
> only happen when you watch livetv?  Is it still there on playback of 
> recorded programs?  

Live TV and recordings alike so don't think it has to do with reaching
the end of the ringbuffer.

Thanks for your time

Steven



More information about the mythtv-dev mailing list