On Tue, Dec 8, 2009 at 7:35 PM, Tom Evans <tevans.uk at googlemail.com> wrote:
> On Tue, Dec 8, 2009 at 9:28 AM, Tom Evans <tevans.uk at googlemail.com> wrote:
>> On Tue, Dec 8, 2009 at 4:02 AM, RC <cooleyr at gmail.com> wrote:
>>> On Mon, 7 Dec 2009 14:13:00 +0000
>>> Tom Evans <tevans.uk at googlemail.com> wrote:
>>>
>>>> So, I checked out mplayer trunk, r29977, and made a few changes to
>>>> support compilation on FreeBSD (see attached diff). The program built
>>>> and compiled successfully, but every file I play through it has the
>>>> video processed way too fast.
>>>
>>> MPlayer syncs based on audio speed, and ao_oss.c is one of the files
>>> you've modified... ?Hmm. ?I would try with some other -ao device to
>>> test this, perhaps -ao esd or similar.
>>>
>>> afm=hwac3 could similarly be a culprit.
>>>
>>
>> Interesting, some things to try tonight. The patch to ao_oss.c is to
>> set the sample rate after pausing/resuming, which was breaking ac3
>> passthrough on my sound card. I'll play around with the audio options
>> some....
>>
>
> I've dropped the ao_oss.c patch - it simply sets the right rate on the
> receiver after pausing, and my receiver seems to cope just fine with
> that anyway, and it is confusing the debugging situation :)
>
> It seems that the problem is with afm=hwac3. Dropping this (and
> outputting 2-channel PCM over the SPDIF) results in perfect timing, as
> does using '-ao none'. I guess that mplayer examines the capabilities
> of the sound device, and that how it does this has changed between the
> working version and the svn trunk version. I also guess its time for
> me to read some code to work out where and why :)
>
> Cheers
>
> Tom
>
Discovered the problem, reverting the following diff fixes it:
------------------------------------------------------------------------
r29750 | cladisch | 2009-10-05 08:42:02 +0100 (Mon, 05 Oct 2009) | 1 line
fix calculation of ao_data.bps for sample formats with more than 16 bits
------------------------------------------------------------------------
Index: libao2/ao_oss.c
===================================================================
--- libao2/ao_oss.c (revision 29749)
+++ libao2/ao_oss.c (revision 29750)
@@ -396,8 +396,19 @@
}
ao_data.bps=ao_data.channels;
- if(ao_data.format != AF_FORMAT_U8 && ao_data.format != AF_FORMAT_S8)
+ switch (ao_data.format & AF_FORMAT_BITS_MASK) {
+ case AF_FORMAT_8BIT:
+ break;
+ case AF_FORMAT_16BIT:
ao_data.bps*=2;
+ break;
+ case AF_FORMAT_24BIT:
+ ao_data.bps*=3;
+ break;
+ case AF_FORMAT_32BIT:
+ ao_data.bps*=4;
+ break;
+ }
ao_data.outburst-=ao_data.outburst % ao_data.bps; // round down
ao_data.bps*=ao_data.samplerate;
In this case, .format is AF_FORMAT_AC3 (256), which gets masked out
for this switch, and matches the AF_FORMAT_8BIT (0) case, and so
doesn't get doubled. I don't know much about sound formats and their
ilk, so wouldn't like to speculate on what the correct fix would be,
but to get a working version I've reverted it for now.
Cheers
Tom
