Mailing List Archive: MythTV: Dev

AC3 playback mangled until timestretch activated

Index | Next | Previous | View Threaded

mwood23 at gmail

Feb 10, 2010, 9:47 PM

Post #1 of 23 (3784 views)
Permalink

AC3 playback mangled until timestretch activated

I posted a couple times in regard to this on mythtv-users. It wasn't
until I read this thread:

http://www.gossamer-threads.com/lists/mythtv/dev/332388

...that I realized I'm suffering the same thing, but in reverse. That
is, I get long audio dropouts on the primary AC3 audio stream -until-
I fiddle with timestretch. Then suddenly everything sounds fine, and
I can get true DD via AC3 passthrough. I can even change the
timestretch back to 1.0x and things continue to run fine.

here's the verbose audio output from playback:

2010-02-10 21:36:05.630 TV: Attempting to change from None to Watching
WatchingPreRecorded
2010-02-10 21:36:06.233 AFD: Opened codec 0x6455110, id(MPEG2VIDEO) type(Video)
2010-02-10 21:36:06.233 AFD: codec AC3 has 6 channels
2010-02-10 21:36:06.234 AFD: Opened codec 0x6455550, id(AC3) type(Audio)
2010-02-10 21:36:06.234 AFD: Audio Track #1 is A/V stream #1 and has 6
channels in the English language(6647399).
2010-02-10 21:36:06.234 AFD: codec AC3 has 2 channels
2010-02-10 21:36:06.235 AFD: Opened codec 0x6455990, id(AC3) type(Audio)
2010-02-10 21:36:06.235 AFD: Audio Track #2 is A/V stream #2 and has 2
channels in the French language(6713957).
2010-02-10 21:36:06.235 AFD: codec AC3 has 2 channels
2010-02-10 21:36:06.236 AFD: Opened codec 0x55885f0, id(AC3) type(Audio)
2010-02-10 21:36:06.236 AFD: Audio Track #3 is A/V stream #3 and has 2
channels in the Unknown language(6648684).
2010-02-10 21:36:06.236 AFD: Trying to select audio track (w/lang)
2010-02-10 21:36:06.236 AFD: Selected track 1: English AC3 5.1ch (A/V Stream #1)
2010-02-10 21:36:06.236 AFD: Initializing audio parms from audio track #1
2010-02-10 21:36:06.236 AFD: Audio format changed
from id(NONE) -1Hz -1ch 0bps to id(
AC3) 48000Hz 6ch 16bps pt
2010-02-10 21:36:06.239 AO: Killing AudioOutputDSP
2010-02-10 21:36:06.239 AO: Original audio codec was AC3
2010-02-10 21:36:06.239 AudioOutputALSA::GetSupportedRates opening
iec958:{ AES0 0x02 }
2010-02-10 21:36:06.241 AO: Sample rate 44100 is supported
2010-02-10 21:36:06.241 AO: Sample rate 48000 is supported
2010-02-10 21:36:06.241 Opening audio device 'spdif'. ch 2(6) sr 48000 (reenc 0)
2010-02-10 21:36:06.241 Setting IEC958 status: non-audio
2010-02-10 21:36:06.242 Opening ALSA audio device 'iec958:{ AES0 0x02 }'.
2010-02-10 21:36:06.243 in SetParameters(format=2, channels=2,
rate=48000, buffer_time=400000, period_time=25000)
2010-02-10 21:36:06.244 get_buffer_size returned 16384
2010-02-10 21:36:06.244 set_period_time_near returned 21333
2010-02-10 21:36:06.244 get_period_size returned 1024
2010-02-10 21:36:06.268 Setting volume to 100
2010-02-10 21:36:06.269 Setting volume to 100
2010-02-10 21:36:06.269 AO: Audio fragment size: 6144
2010-02-10 21:36:06.269 AO: Audio Stretch Factor: 1
2010-02-10 21:36:06.269 AO: kickoffOutputAudioLoop: pid = 19759
2010-02-10 21:36:06.269 AO: OutputAudioLoop: Play Event
2010-02-10 21:36:06.269 AO: Ending reconfigure

and this repeats for a bit...

... and then when I go to .9x timestretch..

2010-02-10 21:36:32.259 AFD: Disabling pass through
2010-02-10 21:36:32.259 AFD: Initializing audio parms from audio track #1
2010-02-10 21:36:32.259 AFD: Audio format changed
from id( AC3) 48000Hz 6ch 16bps pt to id(
AC3) 48000Hz 6ch 16bps
2010-02-10 21:36:32.259 AO: SetEffDsp: 4800000
2010-02-10 21:36:32.259 AO: Reencoding decoded AC3/DTS to AC3
2010-02-10 21:36:32.259 AO: Killing AudioOutputDSP
2010-02-10 21:36:32.260 AO: OutputAudioLoop: Stop Event
2010-02-10 21:36:32.260 AO: kickoffOutputAudioLoop exiting
2010-02-10 21:36:32.261 AO: Original audio codec was AC3
2010-02-10 21:36:32.261 AudioOutputALSA::GetSupportedRates opening
iec958:{ AES0 0x02 }
2010-02-10 21:36:32.263 AO: Sample rate 44100 is supported
2010-02-10 21:36:32.264 AO: Sample rate 48000 is supported
2010-02-10 21:36:32.264 AO: Creating AC-3 Encoder
2010-02-10 21:36:32.264 DEnc: Init codecid=AC3, br=448000, sr=48000, ch=6
2010-02-10 21:36:32.265 DigitalEncoder::Init fs=1536, bpf=12 ofb=18432
2010-02-10 21:36:32.265 Opening audio device 'spdif'. ch 2(6) sr 48000 (reenc 1)
2010-02-10 21:36:32.265 Setting IEC958 status: non-audio
2010-02-10 21:36:32.265 Opening ALSA audio device 'iec958:{ AES0 0x02 }'.
2010-02-10 21:36:32.267 in SetParameters(format=2, channels=2,
rate=48000, buffer_time=400000, period_time=25000)
2010-02-10 21:36:32.268 get_buffer_size returned 16384
2010-02-10 21:36:32.268 set_period_time_near returned 21333
2010-02-10 21:36:32.268 get_period_size returned 1024
2010-02-10 21:36:32.284 Setting volume to 100
2010-02-10 21:36:32.284 Setting volume to 100
2010-02-10 21:36:32.284 AO: Audio fragment size: 6144
2010-02-10 21:36:32.284 AO: Audio Stretch Factor: 1
2010-02-10 21:36:32.284 AO: kickoffOutputAudioLoop: pid = 19759
2010-02-10 21:36:32.285 AO: OutputAudioLoop: Play Event
2010-02-10 21:36:32.285 AO: Ending reconfigure
2010-02-10 21:36:32.287 AO: Using time stretch 0.9

and all runs well, whether I stay at that rate or go back to 1.0x. So
the hardware, drivers, and app are all capable of managing these
multiple AC3 streams. That's good to know! The particular
broadcasts/recordings where these seem to occur have multiple AC3
streams with multiple active channels. But what causes the initial
playback to drop out?

latest version where this occurs.. trunk Revision: 23531

any guidance appreciated. thanks!
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

jyavenard at gmail

Feb 11, 2010, 3:02 AM

Post #2 of 23 (3732 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

Hi

On 11 February 2010 16:47, Matt W <mwood23 [at] gmail> wrote:
> I posted a couple times in regard to this on mythtv-users. It wasn't
> until I read this thread:
>
> http://www.gossamer-threads.com/lists/mythtv/dev/332388
>
> ...that I realized I'm suffering the same thing, but in reverse. That
> is, I get long audio dropouts on the primary AC3 audio stream -until-
> I fiddle with timestretch. Then suddenly everything sounds fine, and
> I can get true DD via AC3 passthrough. I can even change the
> timestretch back to 1.0x and things continue to run fine.

>
> latest version where this occurs.. trunk Revision: 23531
>
> any guidance appreciated. thanks!

When you disable the mixerx (look like you're using "software" mixer).
Does this still happen?

Are you certain your sound amp can handle either AC3 or DTS and that
you have checked passthrough?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mwood23 at gmail

Feb 11, 2010, 8:25 AM

Post #3 of 23 (3722 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

On Thu, Feb 11, 2010 at 3:02 AM, Jean-Yves Avenard <jyavenard [at] gmail> wrote:

>> latest version where this occurs.. trunk Revision: 23531
>>
>> any guidance appreciated. thanks!
>
> When you disable the mixerx (look like you're using "software" mixer).
> Does this still happen?
>
> Are you certain your sound amp can handle either AC3 or DTS and that
> you have checked passthrough?

Hi, Jean-Yves--

yes definitely the amp is capable, Denon AV-1602, connected via
optical S/PDIF to the port on the motherboard. The display goes to
'DOLBY DIGITAL', the proper LED lights up, and the VFD on the amp has
a box that lights up: "DIGITAL" so I'm covered there :-) In most of
the DD-enabled broadcasts that I play back, it's fine (e.g. in
playback, my local station's broadcast of Lost in 720p goes DD sans
problème).

but i'm a newbie with regard to sound driver usage/configuration in
the linux world. In Myth, I have passthrough enabled, and I'm not
doing any volume controls via the General setup. Am I looking for
particular settings in alsamixer, perhaps?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

ylee at pobox

Feb 11, 2010, 9:44 AM

Post #4 of 23 (3713 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

Matt W <mwood23 [at] gmail> says:
> That is, I get long audio dropouts on the primary AC3 audio stream
> -until- I fiddle with timestretch. Then suddenly everything sounds
> fine, and I can get true DD via AC3 passthrough. I can even change
> the timestretch back to 1.0x and things continue to run fine.

Your description resembles, and your log excerpts somewhat resemble,
what I reported at #8030. I hadn't known about the timestretch
workaround but indeed that does work for me.

As noted in the ticket, I'm pretty sure the issue has something to do
with the trunk audio code not handling properly the transition between
a non-AC3 and a AC3 audio track. Applying your observations to my
experiences with other afflicted recordings, another factor appears to
be the presence of a non-AC3 track, like so:

0:15----0:30----0:45
#1 Stereo--AC3---------
#2 None----Stereo------

The Stereo track (upmixed to Dolby Digital) on #1 plays properly until
it swaps to an AC3 track, with the Stereo track moving to the
now-existing #2. This confuses the audio code.

--
Frontend/backend: P4 3.0GHz, 1.5TB software RAID 5 array
Backend: Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs: Four high-definition over FireWire/OTA
Accessories: 47" 1080p LCD, 5.1 digital, and MX-600
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mwood23 at gmail

Feb 11, 2010, 12:30 PM

Post #5 of 23 (3708 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

> Your description resembles, and your log excerpts somewhat resemble,
> what I reported at #8030. I hadn't known about the timestretch
> workaround but indeed that does work for me.
>
> As noted in the ticket, I'm pretty sure the issue has something to do
> with the trunk audio code not handling properly the transition between
> a non-AC3 and a AC3 audio track. Applying your observations to my
> experiences with other afflicted recordings, another factor appears to
> be the presence of a non-AC3 track, like so:
>
> 0:15----0:30----0:45
> #1 Stereo--AC3---------
> #2 None----Stereo------
>
> The Stereo track (upmixed to Dolby Digital) on #1 plays properly until
> it swaps to an AC3 track, with the Stereo track moving to the
> now-existing #2. This confuses the audio code.

Yeechang, that is interesting. In my case, the playback shows all
three streams as AC3 encoded, but indeed, when I switch the playback
to either of the two other streams (which btw, are not French or
Spanish but a descriptive audio channel, and normal stereo channel),
my amp switches back to the default Dolby PL II that I have set up.
When I switch between the DD stream and one of the others, and then
back to DD, I still have sync/dropout issues. Only playing with
timestretch seems to "tickle" the playback into properly handling the
stream.

Should I add my comments to your open ticket? I've only done one of
those bug reports before so I'm not sure about the etiquette! :-)

thanks!
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

ylee at pobox

Feb 12, 2010, 12:27 AM

Post #6 of 23 (3679 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

I wrote:
> As noted in the ticket, I'm pretty sure the issue has something to
> do with the trunk audio code not handling properly the transition
> between a non-AC3 and a AC3 audio track. Applying your observations
> to my experiences with other afflicted recordings, another factor
> appears to be the presence of a non-AC3 track

Further support for this theory came from another recording of
_The Tonight Show with Conan O'Brien_ (in reruns) tonight with proper
audio playback due, I believe, to only having one audio track:

0:15----0:30----0:45
#1 Stereo--AC3---------

This is in contrast to the aforementioned problematic _Tonight_
recording:

0:15----0:30----0:45
#1 Stereo--AC3---------
#2 None----Stereo------

So it's not transitioning from a non-AC3 to AC3 audio that's the
problem; it's doing so with another audio track in the recording. I am
unsure on what would happen if track #2 existed from the start of the
recording like #1.

--
Frontend/backend: P4 3.0GHz, 1.5TB software RAID 5 array
Backend: Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs: Four high-definition over FireWire/OTA
Accessories: 47" 1080p LCD, 5.1 digital, and MX-600
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mwood23 at gmail

Feb 12, 2010, 9:09 AM

Post #7 of 23 (3664 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

On Fri, Feb 12, 2010 at 12:27 AM, Yeechang Lee <ylee [at] pobox> wrote:
> Further support for this theory came from another recording of
> _The Tonight Show with Conan O'Brien_ (in reruns) tonight with proper
> audio playback due, I believe, to only having one audio track:
>
> 0:15----0:30----0:45
> #1 Stereo--AC3---------
>
> This is in contrast to the aforementioned problematic _Tonight_
> recording:
>
> 0:15----0:30----0:45
> #1 Stereo--AC3---------
> #2 None----Stereo------
>
> So it's not transitioning from a non-AC3 to AC3 audio that's the
> problem; it's doing so with another audio track in the recording. I am
> unsure on what would happen if track #2 existed from the start of the
> recording like #1.

hm interesting. So is that a case of the broadcaster sending an AC3
stream that contains 0 channels? Yes it seems to be the multiple
channel count that trips up my myth box. That PBS broadcast that
first alerted me to all of this had three AC3 streams, with a total of
10 active channels, total.

if i have time today, I'll add my experiences as comments to your open
bug ticket, in the hopes that will give it a bit of a push :)
Otherwise, I'll add to it this weekend.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

ylee at pobox

Feb 13, 2010, 1:25 PM

Post #8 of 23 (3605 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

Matt W <mwood23 [at] gmail> says:
> hm interesting. So is that a case of the broadcaster sending an AC3
> stream that contains 0 channels?

The OSD menu shows multiple tracks because there are multiple tracks
within the recording, if not necessarily at the beginning.

0:15----0:30----0:45
#1 Stereo--AC3---------
#2 None----Stereo------

"None" means there is no second audio track at all until the program
with two audio tracks begins.

> Yes it seems to be the multiple channel count that trips up my myth
> box. That PBS broadcast that first alerted me to all of this had
> three AC3 streams, with a total of 10 active channels, total.

I don't believe that the total number of audio channels is relevant,
per se; only that multiple audio tracks exist *and* that not all of
them are present at the start of the recording.

Another interesting finding: The timestretch workaround works even at
the start of the affected recording, before the second audio track
(and consequent issue in playing the first, default, track) begins. In
other words, a quick hack that forces a timestretch change to, say,
1.05X, then back to 1.0X, when playback begins might work.

Again, this is an issue only with the trunk audio code, not with the
0.22 stock code.

--
Frontend/backend: P4 3.0GHz, 1.5TB software RAID 5 array
Backend: Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs: Four high-definition over FireWire/OTA
Accessories: 47" 1080p LCD, 5.1 digital, and MX-600
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

perveilerj at gmail

Feb 19, 2010, 11:40 AM

Post #9 of 23 (3315 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

On Sat, Feb 13, 2010 at 4:25 PM, Yeechang Lee <ylee [at] pobox> wrote:

> Matt W <mwood23 [at] gmail> says:
> > hm interesting. So is that a case of the broadcaster sending an AC3
> > stream that contains 0 channels?
>
> The OSD menu shows multiple tracks because there are multiple tracks
> within the recording, if not necessarily at the beginning.
>
> 0:15----0:30----0:45
> #1 Stereo--AC3---------
> #2 None----Stereo------
>
> "None" means there is no second audio track at all until the program
> with two audio tracks begins.
>
> > Yes it seems to be the multiple channel count that trips up my myth
> > box. That PBS broadcast that first alerted me to all of this had
> > three AC3 streams, with a total of 10 active channels, total.
>
> I don't believe that the total number of audio channels is relevant,
> per se; only that multiple audio tracks exist *and* that not all of
> them are present at the start of the recording.
>
> Another interesting finding: The timestretch workaround works even at
> the start of the affected recording, before the second audio track
> (and consequent issue in playing the first, default, track) begins. In
> other words, a quick hack that forces a timestretch change to, say,
> 1.05X, then back to 1.0X, when playback begins might work.
>
> Again, this is an issue only with the trunk audio code, not with the
> 0.22 stock code.
>
> --
>

"Me too", except that I'm running 0.22-fixes and not trunk. I'm running out
of the JYA repository though so I'm guessing that it probably also has the
new audio code in it.

Of course if it DOESN'T contain the new audio code then I guess I have other
problems :) My symptoms are the same, anyways. Let me know if you want me
to test anything.

--Jack

jyavenard at gmail

Feb 26, 2010, 8:45 AM

Post #10 of 23 (3054 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

Hi

On 14 February 2010 08:25, Yeechang Lee <ylee [at] pobox> wrote:
> I don't believe that the total number of audio channels is relevant,
> per se; only that multiple audio tracks exist *and* that not all of
> them are present at the start of the recording.
>
> Another interesting finding: The timestretch workaround works even at
> the start of the affected recording, before the second audio track
> (and consequent issue in playing the first, default, track) begins. In
> other words, a quick hack that forces a timestretch change to, say,
> 1.05X, then back to 1.0X, when playback begins might work.

[23614] should work around those files with corrupted audio (because
really, that's what they are)

Let me know how it works for you...

Time for bed now

Cheers
Jean-Yves
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

ylee at pobox

Feb 26, 2010, 12:16 PM

Post #11 of 23 (3039 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

Jean-Yves Avenard <jyavenard [at] gmail> says:
> [23614] should work around those files with corrupted audio (because
> really, that's what they are)
>
> Let me know how it works for you...

The changeset fixes the issue in my brief testing, I am glad to
report. There is a momentary pause when video playback starts before
audio starts, but it's almost unnoticeable.

--
Frontend/backend: P4 3.0GHz, 1.5TB software RAID 5 array
Backend: Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs: Four high-definition over FireWire/OTA
Accessories: 47" 1080p LCD, 5.1 digital, and MX-600
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

ylee at pobox

Feb 26, 2010, 9:07 PM

Post #12 of 23 (3043 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

Jean-Yves Avenard <jyavenard [at] gmail> says:
> [23614] should work around those files with corrupted audio (because
> really, that's what they are)
>
> Let me know how it works for you...

After further testing with the original _Tonight_ recording, the
changeset force upmixes the two-track AC3; if I turn the upmixer off
via the OSD, the receiver's display switchs to Pro Logic II. Before
the changeset, with the workaround (using timestretch to switch away
from, then back to, 1.0X) the audio signal is unchanged.

This is visible via the sample clips. It is not possible to switch the
upmixer off with conan.mpg and conan3.mpg, but is possible with
conan2.mpg and conan4.mpg.

--
Frontend/backend: P4 3.0GHz, 1.5TB software RAID 5 array
Backend: Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs: Four high-definition over FireWire/OTA
Accessories: 47" 1080p LCD, 5.1 digital, and MX-600
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

jyavenard at gmail

Feb 26, 2010, 10:42 PM

Post #13 of 23 (3039 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

Hi

On 27 February 2010 16:07, Yeechang Lee <ylee [at] pobox> wrote:
> After further testing with the original _Tonight_ recording, the
> changeset force upmixes the two-track AC3; if I turn the upmixer off
> via the OSD, the receiver's display switchs to Pro Logic II. Before
> the changeset, with the workaround (using timestretch to switch away
> from, then back to, 1.0X) the audio signal is unchanged.

What was your expected behaviour ?

>
> This is visible via the sample clips. It is not possible to switch the
> upmixer off with conan.mpg and conan3.mpg, but is possible with
> conan2.mpg and conan4.mpg.

but conan.mpg and conan3.mpg are seen as having a AC3 5.1 track ; so
upmixer on or off will make no difference.

What is important is the first track seen.
conan2 and conan4 are seen as 2 -> 6 -> 2 -> 6 -> 2 -> 6
While conan.mpg and conan3.mpg are seen as 6 -> 2 -> 6 -> 2 -> 6

If you activate the -v audio and look at the change of the number of
channels in the AC3 track.

You'll see that for conan2 and conan4 , 2 channels AC3 is seen for
several frames, but 6 channels AC3 is only seen for 1 frame only and
vice-versa for conan.mpg and conand3.mpg

So as far as I can tell, it is behaving just as it is supposed to ;
and I can't see the difference on my system between using the
timestretch workaround or the new changeset.

Jean-Yves
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mwood23 at gmail

Mar 1, 2010, 11:47 AM

Post #14 of 23 (2920 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

On Fri, Feb 26, 2010 at 10:42 PM, Jean-Yves Avenard <jyavenard [at] gmail> wrote:
> Hi
>
> On 27 February 2010 16:07, Yeechang Lee <ylee [at] pobox> wrote:
>> After further testing with the original _Tonight_ recording, the
>> changeset force upmixes the two-track AC3; if I turn the upmixer off
>> via the OSD, the receiver's display switchs to Pro Logic II. Before
>> the changeset, with the workaround (using timestretch to switch away
>> from, then back to, 1.0X) the audio signal is unchanged.
>
> What was your expected behaviour ?

Ok so I've been plugging along and recently, the original symptoms of
playback I was experiencing seem to have disappeared. I no longer get
severe audio from playing back the same recordings I was using
previously.

Could it be because I dumped the Debian packaged version of libmpeg2
and ffmpeg and went ahead and compiled my own? I did this so I could
optimize the build of things like libmpeg2, ffmpeg, x264, etc, for the
best possible transcode performance.

sorry if this is somewhat vague, but these playback issues did seem to
clear up before I did any SVN update to the trunk.

Yeechang, are you still seeing similar playback issues with latest trunk code?

mythfrontend info:

mythfrontend --version
Please include all output in bug reports.
MythTV Version : 23626
MythTV Branch : trunk
Network Protocol : 56
Library API : 0.23.20100225-1
QT Version : 4.4.3
Options compiled in:
linux release using_oss using_alsa using_backend using_dvb
using_frontend using_lirc using_mheg using_opengl_video
using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_x11
using_xrandr using_xv using_xvmc using_xvmc_vld using_xvmcw
using_bindings_perl using_bindings_python using_opengl
using_ffmpeg_threads using_mheg

my ffmpeg and libmpeg2 info:

mythtv [at] mythtv:~/src/mythtv/trunk/mythtv$ ffmpeg -version
FFmpeg version SVN-r21693, Copyright (c) 2000-2010 Fabrice Bellard, et al.
built on Feb 16 2010 07:43:25 with gcc 4.3.2
configuration: --enable-pthreads --enable-libmp3lame
--enable-libxvid --enable-shared --enable-gpl --enable-libx264
libavutil 50. 9. 0 / 50. 9. 0
libavcodec 52.52. 0 / 52.52. 0
libavformat 52.51. 0 / 52.51. 0
libavdevice 52. 2. 0 / 52. 2. 0
libswscale 0.10. 0 / 0.10. 0
FFmpeg SVN-r21693
libavutil 50. 9. 0 / 50. 9. 0
libavcodec 52.52. 0 / 52.52. 0
libavformat 52.51. 0 / 52.51. 0
libavdevice 52. 2. 0 / 52. 2. 0
libswscale 0.10. 0 / 0.10. 0

and my libmpeg2 info:

#define PACKAGE "libmpeg2"
#define VERSION "0.5.1"
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mtdean at thirdcontact

Mar 1, 2010, 11:52 AM

Post #15 of 23 (2919 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

On 03/01/2010 02:47 PM, Matt W wrote:
> Ok so I've been plugging along and recently, the original symptoms of
> playback I was experiencing seem to have disappeared. I no longer get
> severe audio from playing back the same recordings I was using
> previously.
>
> Could it be because I dumped the Debian packaged version of libmpeg2
> and ffmpeg and went ahead and compiled my own? I did this so I could
> optimize the build of things like libmpeg2, ffmpeg, x264, etc, for the
> best possible transcode performance.
>

Normally I'd tell you that it's impossible for those system libs to
affect MythTV, but according to
http://svn.mythtv.org/trac/ticket/7796#comment:7 , Debian (or some 3rd
party packager for Debian) is forking MythTV and linking against
external libs instead of the versions that are distributed with, tested
with, compiled with appropriate options for, and known to work with MythTV.

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mwood23 at gmail

Mar 1, 2010, 12:14 PM

Post #16 of 23 (2914 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

On Mon, Mar 1, 2010 at 11:52 AM, Michael T. Dean
<mtdean [at] thirdcontact> wrote:
> Normally I'd tell you that it's impossible for those system libs to affect
> MythTV, but according to http://svn.mythtv.org/trac/ticket/7796#comment:7 ,
> Debian (or some 3rd party packager for Debian) is forking MythTV and linking
> against external libs instead of the versions that are distributed with,
> tested with, compiled with appropriate options for, and known to work with
> MythTV.

yeah I am not about to trace down what library path gets used when and
where :) So I went ahead and ripped out the packaged versions of the
libs altogether. but yeah libmpeg2 is not dynamically linked to any
mythtv libs or binaries. and the only thing that seems to link it is
mpeg2dec. ok nevermind, sorry for the noise!
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

lsorense at csclub

Mar 1, 2010, 12:22 PM

Post #17 of 23 (2914 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

On Mon, Mar 01, 2010 at 02:52:07PM -0500, Michael T. Dean wrote:
> On 03/01/2010 02:47 PM, Matt W wrote:
>> Ok so I've been plugging along and recently, the original symptoms of
>> playback I was experiencing seem to have disappeared. I no longer get
>> severe audio from playing back the same recordings I was using
>> previously.
>>
>> Could it be because I dumped the Debian packaged version of libmpeg2
>> and ffmpeg and went ahead and compiled my own? I did this so I could
>> optimize the build of things like libmpeg2, ffmpeg, x264, etc, for the
>> best possible transcode performance.
>>
>
> Normally I'd tell you that it's impossible for those system libs to
> affect MythTV, but according to
> http://svn.mythtv.org/trac/ticket/7796#comment:7 , Debian (or some 3rd
> party packager for Debian) is forking MythTV and linking against
> external libs instead of the versions that are distributed with, tested
> with, compiled with appropriate options for, and known to work with
> MythTV.

In the case of debian it would be a 3rd party (debian-multimedia.org).

I for one an highly in favour of what is being done, and despise
when projects start demanding which versions of libraries to use, and
linking staticly. It's pathetic. If the libraries are that flacky
and unstable, they should be fixed (or not used), and if they are not,
then it should work with any version that is at least at a certain known
good enough revision.

We don't need the bloat of staticly linked applications, and shared
libraries mean only one version of a library needs fixing when a bug or
security problem is found, rather than having to recompile a bunch of
staticly linked applications.

--
Len Sorensen
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

stuart at tase

Mar 1, 2010, 12:50 PM

Post #18 of 23 (2912 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

On Monday 01 Mar 2010 20:22:56 Lennart Sorensen wrote:
> We don't need the bloat of staticly linked applications, and shared
> libraries mean only one version of a library needs fixing when a bug or
> security problem is found, rather than having to recompile a bunch of
> staticly linked applications.

When you have to maintain said application, dealing with ever changing APIs
and the hundreds of support requests for bugs and behaviour changes which are
present in some versions of a lib but not others, then you get to make the
decisions.

Users expect mythtv to be stable, for it to compete against proprietary
applications and DVRs which get to not only determine the libs they use but
the hardware too. #7796 is a perfect example of what can go wrong when users
don't use the libs we include, everyone suffers, we have to deal with the
tickets it generates even though it's not our problem and the users have a
broken system. It's not even as though those libs add tens of MBs to the
download, the suggestion that including them results in bloat is ridiculous.

The choice made by Christian is unpopular with the devs and it's even been
suggested that we force the Debian port to change names ala IceWeasel/FireFox
because we don't have the time to deal with breakages introduced by packagers
who think they know better.
--
Stuart Morgan
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

lsorense at csclub

Mar 1, 2010, 1:01 PM

Post #19 of 23 (2915 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

On Mon, Mar 01, 2010 at 08:50:24PM +0000, Stuart Morgan wrote:
> When you have to maintain said application, dealing with ever changing APIs
> and the hundreds of support requests for bugs and behaviour changes which are
> present in some versions of a lib but not others, then you get to make the
> decisions.

I guess mythtv must be using some badly designed libraries then, if the
API keeps changing in ways that break things. Lots of libraries don't
have this problem, in fact I would say the vast majority.

So which libraries are causing these problems?

> Users expect mythtv to be stable, for it to compete against proprietary
> applications and DVRs which get to not only determine the libs they use but
> the hardware too. #7796 is a perfect example of what can go wrong when users
> don't use the libs we include, everyone suffers, we have to deal with the
> tickets it generates even though it's not our problem and the users have a
> broken system. It's not even as though those libs add tens of MBs to the
> download, the suggestion that including them results in bloat is ridiculous.

It may not amount to much diskspace, but it does mean yet another copy
of a lib to maintain if something needs fixing.

> The choice made by Christian is unpopular with the devs and it's even been
> suggested that we force the Debian port to change names ala IceWeasel/FireFox
> because we don't have the time to deal with breakages introduced by packagers
> who think they know better.

Well Debian does have a policy of not allowing staticly linked
applications except in exceptional cases (like staticly linked recovery
shell and such). Christian is simply trying to package mythtv to the
high standards Debian expects. Perhaps mythtv (or more likely some of
its libraries) just isn't ready to be held to that high of a standard yet.
Hopefully this is fixable.

--
Len Sorensen
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mwood23 at gmail

Mar 1, 2010, 1:41 PM

Post #20 of 23 (2915 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

On Mon, Mar 1, 2010 at 1:01 PM, Lennart Sorensen
<lsorense [at] csclub> wrote:
> Well Debian does have a policy of not allowing staticly linked
> applications except in exceptional cases (like staticly linked recovery
> shell and such). Christian is simply trying to package mythtv to the
> high standards Debian expects. Perhaps mythtv (or more likely some of
> its libraries) just isn't ready to be held to that high of a standard yet.
> Hopefully this is fixable.

Ok I don't mean to derail the original thread..I'm not sure that my
compiling the ffmpeg binary and/or libmpeg2 lib actually were the
things that seemingly cured my playback issues.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

jyavenard at gmail

Mar 1, 2010, 2:00 PM

Post #21 of 23 (2919 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

Hi

On 2 March 2010 08:01, Lennart Sorensen <lsorense [at] csclub> wrote:
> I guess mythtv must be using some badly designed libraries then, if the
> API keeps changing in ways that break things. Lots of libraries don't
> have this problem, in fact I would say the vast majority.

ROFL..

Have you ever looked at ffmpeg and the h264 libraries ?

Why do you think mplayer is so rarely upgraded on either debian or ubuntu?
It's such a pain to update it, because it always expect specific
version of the libraries, in particular h264 and will only compile
with a recent one.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

lsorense at csclub

Mar 1, 2010, 2:29 PM

Post #22 of 23 (2905 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

On Tue, Mar 02, 2010 at 09:00:16AM +1100, Jean-Yves Avenard wrote:
> ROFL..
>
> Have you ever looked at ffmpeg and the h264 libraries ?

I had a suspiccion those were involved. I actually have seen small
issues that made me think the firewire libraries have compatiblity issues
between versions too.

This doesn't mean those shouldn't be put into a sane state where they
don't keep breaking things.

> Why do you think mplayer is so rarely upgraded on either debian or ubuntu?
> It's such a pain to update it, because it always expect specific
> version of the libraries, in particular h264 and will only compile
> with a recent one.

Well mplayer for the longest time was against runtime cputype detection
for selecting assembly optimizations to use, so I am not going to think
too much of its issues.

--
Len Sorensen
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

ylee at pobox

Mar 17, 2010, 12:55 AM

Post #23 of 23 (2129 views)
Permalink

Re: AC3 playback mangled until timestretch activated [In reply to]

Matt W <mwood23 [at] gmail> says:
> Yeechang, are you still seeing similar playback issues with latest
> trunk code?

I don't use Debian so Mike Dean's answer would likely apply in your
case (based on your description), but:
<URL:http://www.gossamer-threads.com/lists/mythtv/dev/425038#425038>.

--
Frontend/backend: P4 3.0GHz, 1.5TB software RAID 5 array
Backend: Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs: Four high-definition over FireWire/OTA
Accessories: 47" 1080p LCD, 5.1 digital, and MX-600
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads